case study for agile software development:
TRANSCRIPT
SOLO: An Agile Case StudyJOE CRESPO
@atendesign aten.io
Aten helps tell the world’s most important stories.
Joe CrespoDIRECTOR OF ACCOUNTS
What are we here to talk about?
Digital projects are risky
The reality…1. 39% of all projects succeed
Delivered on time, on budget, and with required features and functions.
2. 43% are challenged Late, over budget, and/or with fewer than the required features and functions.
3. 18% fail Either cancelled prior to completion or delivered and never used.
Source: https://www.wrike.com/blog/complete-collection-project-management-statistics-2015/#failure
What are we here to talk about?1. Take ownership of your digital project.
2. Manage your stakeholders.
3. Get the most out of your team.
What is
Agile?
What is
Agile?
Agile is the common tongue of digital teams
1. 16% of tech teams are pure agile
2. 51% lean towards agile
3. 24% hybrid of agile and waterfall
4. 7% lean towards waterfall
5. 2% are pure waterfall
Survey conducted in 2015.Source: http://techbeacon.com/survey-agile-new-norm
A common vocabulary and…Understanding agile principles requires no in-depth technical knowledge and can help you better understand your product.
“ You can have a room full of the best experts but if they cannot communicate, you will not get anything done.
Thanks to an agile approach we [the SOLO team] have succeeded in developing our own language and culture that everyone on the team can understand.
– Pauline L, Product Owner
Agile
Values
The Four Values1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Source: http://agilemanifesto.org/
Not everything is a nailChoose a solution that works
Agile is the New Waterfallby Amir Yasin
http://bit.ly/new-waterfall
Counterpoint:
Recipes
TODAY’S SPECI AL: SCRUM
Chefs: The Team*• Product Owner
Sets the direction for the project.
• Scrum MasterTeam facilitator, clears blockers for the project, and runs defense against distractions.
• Team MemberThese are the role players on the project: the designer, the architect, the developer… etc.
* Again, we are focusing on Scrum.
A Few Ingredients• Epic • User Story • The Product Backlog
Ingredient: EpicHigh level features of a digital product.
Epic Pitfalls• Epics are a high-level view of the work. Keep the number of
epics to a human scale. No more than 7-10. If you have more than that, it will be difficult to get your arms around the project.
Ingredient: User StoryA discrete feature written from a user’s perspective with a defined end point or acceptance criteria.
“ As an applicant I need to share my email address so that I receive notifications relevant to me.
“ As a [type of user] I need to [take an action] so that [I achieve a goal]
“ As a [who] I need to [what] so that [why]
Story and Acceptance CriteriaAs an applicant I need to share my email address so that I can receive notifications relevant to me.
1. Create a form that collects email addresses. 2. Create a block that displays that form within a region of the page. 3. Style the block so that it matches the project’s style guide.
Acceptance Criteria
• Keep to the “As a [who] I need to [what] so that [why]” format. You will be tempted to drop the “as a” and “so that” parts.
• The user should be well-defined. “As a person…” is not specific enough.
• Avoid conjunctions like ANDs and ORs.Example: “As an applicant, I want to share my email AND read the privacy policy so that I receive notifications OR opt out of doing so.”
• No more than 5 items in the Acceptance Criteria.
• Sometimes project tasks are just tasks.
User Story Pitfalls
Ingredient: The Product BacklogThis is simply a collection of User Stories, organized by priority.
• Expect the Product Backlog to evolve.
• You will have some low priority stories in your backlog that you will never actually invest time implementing.
• Do not conflate project launch with completing the Product Backlog.
Product Backlog Pitfalls
Ingredients Recap• Epic • User Story • The Product Backlog
1 2
Directions: Sprints and Ceremonies
Development cycles are organized around sprints.
Top priorities in the product backlog are loaded into the sprint.
Sprints are time-boxed.
1. Sprint Planning
2. Daily Standup
3. Review
4. Retrospective
Sprints The Four Ceremonies
• The team must agree to User Stories that get loaded into the sprint, not simply assigned work.
• You will be tempted to not honor the time-box.
Sprint Pitfalls
• Stick to them!!
• Keep them short.
• Be agile about agile.
Ceremony Pitfalls
Let’s Get to Cooking
“ This SOLO Team is the Dream Team: it's small, flexible, each person is the perfect representative of their role on the boat yet always reaching out to the other crew members to see how they can help.– Pauline L, Product Owner
What is our client getting right?
Product Owner Mentality1. Knows her site is a user-centered software product.
2. Regularly reaches out to her audience, not just stakeholders.
3. She is aware that the design/build is the first step and she needs to maintain the site, as well as refine and extend the site after launch.
Understands Her Users1. She drew up initial personas prior to our engagement.
2. She keeps her personas on the wall in her office as a constant reminder.
Manages Stakeholders1. Takes prototypes to stakeholders to get them involved early.
2. She weighs the importance of all stakeholder requests against the rest of her Product Backlog.
High Availability1. She keeps a shared Slack channel open.
2. She is quick to get on a call.
3. Aten uses JIRA as a ticketing management system, and Pauline works in JIRA alongside the Aten team.
1. Wrote all the initial User Stories prior to our engagement.
2. Sets a business value against each Story.
3. Refines the User Stories with the Aten team and is open to rewriting, discarding and splitting Stories.
Owns the Product Backlog
“ The more the Product Owner understands the work implied, the better because the Product Owner is empowered to re-frame, contribute ideas, make better decisions for the users, and prioritize the work.
– Pauline L, Product Owner
1. She confirms with the developers that all Stories are development-ready before investing development time.
2. She insists that the current Sprint’s time-box is honored.
3. She insists that the current Sprint have Planning, Reviews and Retros.
4. Decisions are delayed so detailed planning is best informed.
Short Term Strict,Long Term Flexible
She will not agree to any User Story going into a Sprint that does not:
1. have clear Acceptance Criteria associated with it.
2. have story points determining the story’s level of complexity.
Owns Development Sprints
“ Everyone knows exactly what they have to do in order to complete a story and everyone shares the same vision of what the result will look like.
Transparency, no confusion, no disappointment.
– Pauline L, Product Owner
1. Sprint Planning
2. Daily Standup
3. Sprint Review
4. Retrospective
Joins the Ceremonies
“ Our culture has rituals, ceremonies. They help us know what's coming, what's expected, they make things a bit more predictable.
– Pauline L, Product Owner
Ceremony 1
Honestly, this took some trial and error
Planning
1. The entire team meets.
2. We read User Stories from the Product Backlog.Note: priority and development readiness on User Stories are determined before Sprint Planning.
3. Thumb voting on each User Story.Anyone on the team can stop a Story from being loaded into the Sprint.
Sprint Planning: Our Approach
Ceremony 2
We went async for this
Standup
1. Our Standups are conducted via a shared Slack channel.
2. A daily reminder asks the three questions:
1. What did you do yesterday?
2. What are you doing today?
3. What, if anything, is blocking your progress?
3. Everyone on the team — this includes Pauline — answers these questions at the start of the workday.
Daily Standup: Our Approach
Ceremony 3
Async, then meet
Review
1. Pauline reviews each User Story on her own in JIRA, either clearing or reassigning them.
2. The team meets:
1. We high five each other over new functionality
2. We discuss any issues that did not clear Pauline’s review.
3. We count up the story points cleared and move unfinished Stories to the next Sprint.
Sprint Review: Our Approach
Ceremony 4
Getting honest with one another
Retro
1. The retro asks everyone on the team:
1. What went well?
2. What do not go so well / could be improved?
3. What, if anything, should be added to/removed from our process in the next sprint?
2. Everyone on the team gets the floor for 90 seconds, followed by an open discussion that focuses on identifying 2 to 3 improvements.
Retrospective: Our Approach
“ This is all about making work visible, I know exactly where we are in the project and what remains to get done. Which is essential for budget planning, stakeholder relations, in short, the survival of the project.
– Pauline L, Product Owner
Conclusion
SOLO: An Agile Case StudyJOE CRESPO