Simulating a Waterfall Project In The Classroom

The first simulation in my course about agile methodologies will be waterfall style. Here’s how I plan to do it.

Before we go into the details of the waterfall simulation, I want the whole group (around 20-30 people) to come up with requirements for the product to build: an online office suite (maybe the most boring but also the most well known thing in the world). I plan to gather the requirements upfront because I do not want to burden the first simulation with this additional task – all simulations should start mostly from the same starting point. The team will be free to document the requirements as they like, no special format required (those special formats of recording and managing requirements will be part of the individual simulations). When we have a good set of requirements, we’ll start with the first project waterfall style.

Splitting The Team

To simulate real world scenarios, I’ll split the team into four groups. Every group shall work on a sub-module of the online office suite. To simulate typical hand-offs between analysts and designers, etc. each group will first do the analysis of one module. Then the results of the first phase will be handed over to the next team for doing design. In the second phase, every team will do design another module as before. After the design stage, again the same story: Every team will hand over the design documents to the next group for development. And the same will happen for testing. That way every team will do every phase – but with a different module each time.

The Analysis Phase

In the first phase, the team will have two tasks:

1. Write use cases based on the initial requirements
2. Plan the project using a Gantt-Chart

I’ll hand out templates for the use case documents. The team will have to identify actors, come up with reasonable use cases and make sure they structure them by including and extending use cases and sub-use cases. The outcome will be a set of documents and a use case diagram.
After coming up with all the use cases, the team has to estimate the use cases and create a project plan with all dependencies and resource allocations. Of course, there will be “bottleneck” resources: a specialist team member, who is the only one to be able to do a certain type of tasks ;-). The output of this exercise will be a big, hairy Gantt-chart. I’m already looking forward to tell the teams to do a tiny, little change shortly before the end of the phase 😉

The Design Phase

Now every team has to hand over their use cases and project plan to the next team for designing a solution. In the design phase I’ll ask the teams to come up with class and sequence diagrams and a database model (in 3rd normal form, of course). The team will have to create a multi-tier SOA with a MVC based front-end. Just the common stuff 😉

The Implementation Phase

After yet another hand-off, every team will start implementing the design. They will write pseudo code on cards and draw screen scribbles. Later, a “user” can interact with the UI by announcing where he would click or what he would type. Then the “CPU” (just another team member) has to try to interpret the pseudo code.

The Test Phase

In the last phase, the development team and the test team have to interact to ensure, that the written pseudo code and the scribbled screens are correct.
A “user” and a “CPU” will try to run the pseudo code. The user will announce how he interacts with the screen and the CPU will try to do what is written in pseudo code and come up with the required changes in the UI and data. If the CPU cannot execute a piece of pseudo code or the result is not what the user expects, there will be an “exception”. For every exception there will be a trouble ticket and the “developers” of the feature have to fix it.

End of The Waterfall Simulation

When every module has ventured through all four phases, we will do a “post-mortem” analysis of the problems and the achieved goals and record some key learnings. Documenting the experiences of every simulation is essential to be able to compare all three approaches.

What do you think about my approach on simulating a waterfall project in a class setting? Do you have any questions or ideas on how to improve it or what could go wrong? I would be very grateful for your feedback. Just leave a comment below.