Currently, I’m preparing for teaching my next course on Agile Methodology. Again and again, I wonder what is the single most important thing my students should be able to take with them after four full days. One of my core messages is definitely that agile is more about principles than about practices. If you absorb the principles you have a good chance to get it right no matter which practices you decide to use or not. But, even teaching the underlying principles seems not enough to me. Tacit knowledge is far too important to be completely ignored in any course. So how can I transfer tacit knowledge in a course setting?
Hands on Simulation
This year I want to go for hands-on simulation of a software development project. The students shall run a simulated project multiple times, using different processes. I’m sure they’ll learn more from doing rather than me talking for four days.
I’m planning to start with simulating the project using a waterfall methodology. I’ll split my students into four teams. They’ll work on four modules in parallel. In the first phase all of them will work as analysts trying to define the requirements for their module and planning the complete project using Gantt-Charts.
In the second phase, all teams will work as designers specifying the features. But as it happens in the real world, none of the teams will work on the same module as before. Every team has to hand over the requirements they came up with to the next team, which has to do the detailed specs.
Same will be true for the development and testing phases.
Let’s see how much they’ll get done in that setup, and how they’ll react to changes in requirements during the later phases.
The next round shall simulate a typical agile project with timeboxes and cross functional teams. Every module will be assigned to exactly one team and that team will try to develop the feature in iterations based on a backlog. The main tools for the teams will be a backlog of requirements (in the form of user stories), iterations and velocity for planning and retrospectives to adapt. Of course requirements will change during this simulation, too.
Lean Software Development
The final round shall simulate a typical lean software development project where the teams do not work in iterations anymore but use a Kanban system to let requirements flow through. The main tools to be used will be a story board, story cards, and cycle time for planning. The team shall learn to see waste and eliminate it.
Having run smaller simulations embedded in former lectures I’m curious to see how such a full blown sim will work out. Do you have any experiences in project management simulation games? How did it go? Let us know in the comments!