Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Case study for agile software development:

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.

  • Login to see the comments

  • Be the first to like this

Case study for agile software development:

  1. 1. SOLO:
 An Agile
 Case Study JOE CRESPO
  2. 2. @atendesign
  3. 3. Aten helps tell the world’s most important stories.
  4. 4. Joe
  5. 5. What are we here to talk about?
  6. 6. Digital projects are risky
  7. 7. 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:
  8. 8. 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.
  9. 9. What is Agile?
  10. 10. What is Agile?
  11. 11. 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.
  12. 12. A common vocabulary and… Understanding agile principles requires no in-depth technical knowledge and can help you better understand your product.
  13. 13. “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
  14. 14. Agile Values
  15. 15. 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:
  16. 16. Not everything is a nail Choose a solution that works Agile is the New Waterfall
 by Amir Yasin Counterpoint:
  17. 17. Recipes TODAY’S SPECIAL: SCRUM
  18. 18. 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.
  19. 19. A Few Ingredients • Epic • User Story • The Product Backlog
  20. 20. Ingredient: Epic High level features of a digital product.
  21. 21. 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.
  22. 22. Ingredient: User Story A discrete feature written from a user’s perspective with a defined end point or acceptance criteria.
  23. 23. “As an applicant I need to share my email address so that I receive notifications relevant to me.
  24. 24. “As a [type of user] I need to [take an action] so that [I achieve a goal]
  25. 25. “As a [who] I need to [what] so that [why]
  26. 26. 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
  27. 27. • 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
  28. 28. Ingredient: The Product Backlog This is simply a collection of User Stories, organized by priority.
  29. 29. • 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
  30. 30. Ingredients Recap • Epic • User Story • The Product Backlog
  31. 31. 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
  32. 32. • 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
  33. 33. Let’s Get to Cooking
  34. 34. “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
  35. 35. What is our client
 getting right?
  36. 36. 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.
  37. 37. 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.
  38. 38. 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.
  39. 39. 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.
  40. 40. 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
  41. 41. “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
  42. 42. 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
  43. 43. 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
  44. 44. “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
  45. 45. 1. Sprint Planning 2. Daily Standup 3. Sprint Review 4. Retrospective Joins the Ceremonies
  46. 46. “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
  47. 47. Ceremony 1 Honestly, this took some trial and error Planning
  48. 48. 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
  49. 49. Ceremony 2 We went async for this Standup
  50. 50. 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
  51. 51. Ceremony 3 Async, then meet Review
  52. 52. 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
  53. 53. Ceremony 4 Getting honest with one another Retro
  54. 54. 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
  55. 55. “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
  56. 56. Conclusion
  57. 57. SOLO:
 An Agile
 Case Study JOE CRESPO