How Agile (Scrum) is working for our team. Take a look at our methodology, how we're organizing the project, how we're approaching the 4 ceremonies, and how our practice might work for you.
8. 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
9. 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.
14. 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
15. A common vocabulary and…
Understanding agile principles requires no in-depth technical
knowledge and can help you better understand your product.
16. “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
18. The Four Values
1. 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/
19. Not
everything is
a nail
Choose a solution that works
Agile is the New Waterfall
by Amir Yasin
http://bit.ly/new-waterfall
Counterpoint:
21. Chefs: The Team*
• Product Owner
Sets the direction for the project.
• Scrum Master
Team facilitator, clears blockers for the project, and runs defense
against distractions.
• Team Member
These are the role players on the project: the designer, the
architect, the developer… etc.
* Again, we are focusing on Scrum.
24. 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.
25. Ingredient: User Story
A discrete feature written from a user’s
perspective with a defined end point or
acceptance criteria.
26. “As an applicant
I need to share my email address
so that I receive notifications
relevant to me.
27. “As a [type of user]
I need to [take an action]
so that [I achieve a goal]
29. Story and Acceptance Criteria
As 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
30. • 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
31. Ingredient: The Product Backlog
This is simply a collection of User Stories, organized by priority.
32. • 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
34. 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
35. • 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
37. “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
39. Product Owner Mentality
1. 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.
40. Understands Her Users
1. She drew up initial personas prior to our engagement.
2. She keeps her personas on the wall in her office as a constant
reminder.
41. Manages Stakeholders
1. 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.
42. High Availability
1. 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.
43. 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
44. “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
45. 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
46. 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
47. “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
49. “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
51. 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
53. 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
55. 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
57. 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
58. “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