About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Waterfall to Agile demo

Few months ago, Rajesh Babu and myself did an Agile training for an organization in Bangalore. This was a 2 day training on agile. Objective of the training was to give everyone [Head of engineering, PM, Tech leads, Developers, QA, Product owners, Marketing people, etc] a very high level understanding of what we mean by Agile.

This company was already or was about to get their CMM certification done. Though they did not have a great process in place, most of the stuff they did resembled very closely to a waterfall approach. So the first task for us was to make them realize and speak out their pain points. Once we had them state/realize what issues they were facing, it would be easy to try and show how some Agile principles can help them.

We knew that the first part of the training would be the turning point. And we wanted some kind of an activity which would do the following job:

  • Break the ice. Get everyone involved. Get them speaking. A presentation would kill everyone‘s enthusiasm. But an activity would be interesting.
  • Rather then us bitching about Waterfall, we wanted them to realize the pain points. We also did not have a great understanding of their process. So there was a potential for it to backfire if we bitched about waterfall.
  • Try and swap roles. Put developers in customer‘s shoes and vice-versa
  • Enforce the importance of communication and feedback on a software projects
  • Not to introduce Agile as something from a different planet. We wanted to introduce Agile as an adaptive and intuitive learning experience where one can feel the importance of feedback.
  • To squeeze the whole project into a 10–15 min activity to demonstrate some of the short comings of Waterfall.
  • Ideal for a team of 7–8 people. But can one can have multiple teams.

Having the objective in place, it was easy to come up with an exercise/activity. We devised a small 75 mins activity for the same.

The activity was broken into two phases, the waterfall cycle followed by a “invent your own process based on the learning” cycle. In both the phases, the customer is shown an image which they need to internalize and then express it to the rest of the team. We had chosen 2 different types of bicycle as our products. The end result of the activity was a drawing of the bicycle [which is the product that the software team is developing for the customer]. In this context, drawing = coding/development.

General rules:

  • Roles required: Total 8 people
    • Customer [1 person]
    • Business Analyst [BA] [1 person]
    • Architect/Designer [2 people]
    • Implementers [2 people]
    • Tester [1 person]
    • Observer [1 person]
    • Actual developers play the role of the customer, testers play the role of the developers, customers become architects, etc.

  • Nobody can talk to each other, they can communicate only by writing down on a paper
  • The final deliverable is the drawing.

Rules for Waterfall life cycle game: Total time 14 mins

  1. Initially we quickly display the actual product [print out of the image] to the Customer for 1 min. The Customer needs to internalize the product.
  2. Then the customer explains the product to the BA for 2 mins. The customer and the BA can communicate via writing on a board/paper
  3. The BA then gets 1 min to write a requirement specification document
  4. This requirement spec doc is handed over to the architect/designer and tester. They have 2 min to clarify the doubts via writing.
  5. The Architect then gets 1 min to write the design specification
  6. Implementation phase – 3 mins : Designer/Implementers and testers cannot interact with each other at this stage
    • Implementers start drawing : [Customer and Analyst are not involved. Designers cannot draw.]
    • Testers come up with a Test plan/ Test cases
  7. Testers get 1 min to test. They cannot communicate with the implementers
  8. 1 minute to fix the bugs reported by the testers and prepare the deliverable. Testers and implementers cannot communicate with each other
  9. The analyst presents the drawing to the customer and they have 1min to do the UAT. They can write down bugs on a sheet of paper.
  10. Last 1 min is given to the implementers to fix the customer reported bugs and send it back

Rules for “Invent your own process” cycle game: Total time 8 mins

  1. Initially we quickly display the actual product [print out of the image] to the Customer for 1 min. The Customer needs to internalize the product.
  2. The team gets 7 mins to implement [draw] the product. The team [Customer, Analyst, Designer, Implementers and Tester] can communicate via writing on a board/paper. Customer and Analysts cannot draw, but Designer can draw.

Collect artifacts at each stage.

Overall Schedule: Total time 75 mins

  1. 10 mins: Ask people to introduce themselves and experience and what they expect out of the session
  2. 10 mins: Brief them about the activity. Talk about the waterfall cycle.
  3. 14 mins: Execute the waterfall cycle
  4. 10 mins: Quick retrospective on the waterfall cycle. Try to highlight what worked and what needs improvement. May be ask each role to explain what they felt about the activity. Note down important points that you want to bring out as difference between Waterfall and agile.
  5. 5 mins : Explain the rules for the “Invent your own process” cycle.
  6. 10 mins: Based on the retrospective notes, each team discusses locally what changes they will make to the current process. At the end of this 10 mins, the team will come up/invent their own process to over come issues highlighted in the previous cycle.
  7. 8 mins : Execute the “invent your own process” cycle
  8. 10 mins : Retrospective

    Licensed under
Creative Commons License