Like swimming you can learn certain things only by practicing them. In IT, this is especially true for agile methods like Scrum or Kanban. Although agile methods are usually simple to understand and make perfectly sense in theory, they are difficult to master in practice. Real-life simulations, blended with some theory, offer an excellent way to experience ‘Agile’, recognize the value and last but not least: It’s fun! (I will come to the LEGO part later). In the area of IT Service Management we use at Glenfis since many years successfully various simulations like Apollo 13, Grab@Pizza or recently Polestar. In the area of Agile we have gained extensive experience by trying out various simulations. In the following, I would like to share with you my experience with four of them: Ball Game, Paper Plane Factory, Lego4Scrum and the Scrum Challenge of Egypt.
Getting started: The Ball Game
The ball game is a very quick and effective way to practice many of the agile principles. I use it as the intro element in every Scrum Master class, ITIL CSI class and as a preparation to the Lego4Scrum Simulation – it’s just a ‘must’.
The whole simulation takes only 20 minutes and the goal is simple: You are a self-organized team and have to get as many Ping-Pong balls from Box A to Box B. The rules are simple as well:
- Everyone has to touch each ball at least once. Passing it to your neighbor at left or right hand side is not allowed The person who touched the ball at the beginning has to touch it also at the end. Ball on the floor = no point.
- Everything is timeboxed: 2 minutes preparation, 5 sprints à 2 minutes, 2 minutes retrospective after each sprint for improvements for the following sprint
- The results (# of balls & improvements for next sprint) are captured after each sprint on a flip chart
- As an instructor you have to ensure that above rules and timeframes are communicated & followed
It’s always interesting to see how the teams evolve over the 5 sprints. The first one is always chaotic; the team maybe reaches 20 balls. But after each iteration they get better and come up with improved way to deal with the situation:
From a learning perspective the ball game is very effective. It covers many agile principles:
- Self-organization: The team has to organize itself to reach the goal (getting as many balls from A to B). Nobody tells them ‘how’
- Empirical process control & Iteration: The team goes over and over the process that was performed by them and decides how to improve it. Decisions are based rather on observation and experimentation than upfront planning. The resulting effiency and quality is much higher than if it’s done in the traditional way.
- Collaboration: Delivering results is a shared value creation process that needs the whole team working and interacting to create the greatest value.
- Time boxing: Time is treated as a limiting constraint and time-boxing is used as a rhythm to which the team works and contributes.
One downside of this exercise is that it only covers the execution side of agile (the sprints). Creating user stories, design etc. is not part of it, but that’s ok to have something to start with and to get the Agile idea.
Variation: The Airplane Factory Game
Same as in the ball game, there are sprints à two minutes and retrospectives, but this time it’s about building paper airplanes. The airplanes have to fulfil certain acceptance criteria and are tested by a QA person and finally the product owner at the end of each sprint (e.g. acceptance criteria: plane flies 2 meters). A line production concept has to be followed – meaning each person has to produce a part of a plane and not each person produces entire planes. The engineering of production – the process to follow – is a team decision. You can also include a prototyping session at the beginning.
I find this simulation interesting as well. Testing if the paper planes fly (or crash) is fun. It’s more advanced compared to the ball game, so less suited as an intro to Agile.
Lego4Scrum: Practicing Scrum end-to-end with LEGO™
Lego4Scrum is what I would call a ‘full-blown’ simulation. Scrum is practiced end-to-end, from production vision to sprint execution and retrospective. It’s license-free and lego4scrum.com provides an instructor manual in 17 languages. We use our own slightly adapted version – up to 40 people with remote teams over video conference!. The required time is 2 hours minimum up to a full-day (if it is combined with some theory, the ball-game or an estimation exercises).
— Alex Lichtenberger (@a_lichtenberger) April 15, 2015
The simulation basically goes like this:
- Organizing the teams: The instructor plays the role of the Product Owner (it’s his product) and he has one or more scrum teams of 4-7 members to achieve this. Each team has a scrum master. The main building elements are LEGO™ bricks, but they can also use other stuff
- Project chartering: The product owner presents the product vision: A city with certain features… (create your own vision)
- Building the Prioritized Backlog: The product owner present now the backlog, ideally in form of user stories. Typically the city should contain things like apartments, schools, a hospital, a bridge, a park, bus stop, etc. All this together form the product backlog. You can include epics, themes, dependencies, etc. but I wouldn’t make it too complicated
- Estimating: The teams have to estimate the user stories. There are various techniques in Scrum, usually I introduce here the planning poker method (with real cards). This part is very important, because it’s not only about estimating, but also about really challenging and understanding the requirements and implications.
I usually play three sprints à six minutes; each sprint is followed by a 2 minutes review and retrospective.
- Sprint Planning: As the product backlog is now ready and the user stories estimated, you are now able to plan what comes into the next sprint (or multiple sprints, you can extend this to a release plan). At the end of this, the teams have their sprint scrum board ready (‘to do’)
- Sprinting: Execution. Now the team ‘builds’ the city, respectively what is in the scope of the sprint. The sprint board has of course to be updated by the team
- Daily Standup: I do this only once by stopping a sprint and ‘exercising’ a daily standup meeting. ‘What did I do / will I do?’ – ‘are there any impediments / hurdles I have to bring to the audience?’ are the questions each team member has to answer
- Sprint Review: the product owner formally reviews the aprint result. One typical situation here is that the product owner has to reject the bridge, because the car is not practically able to pass it.
- Sprint retrospective: After each sprint the team performs a ‘lessons learned’: What went well? What didn’t? What can be done better in the next sprint?
- The above is done 3 times, followed by a final debriefing
It’s also interesting to build in ‘unplanned’ things like the product owner coming up with new or changed requirements after the first sprint or team-members being ‘ill’ for a sprint. That’s real situations, isn’t it? I made very positive experiences with the Lego4Scrum simulation. Not only because it covers the whole Scrum process, but also because playing Lego is a lot of fun and the combination of both brings a big learning effect. Although this simulation exists for about four years there is a kind of revival, maybe because Lego in general has become more and more popular around the world recently.
Agile meets Waterfall: The Scrum Challenge of Egypt
In the ‘Scrum Challenge of Egypt’, the Scrum team has to build a pyramid to fulfil the needs of the Pharaoh (he is the product owner). This is a Scrum adaption of the very successful project management simulation ‘Challenge of Egypt’ by Gaming Works. This means it was developed by taking a traditional waterfall-simulation and building Scrum-elements into it, in this case mainly on the execution side. In this simulation you will therefore find traditional roles like ‘line manager’ or ‘financial management’. If you are an agile enthusiast you may think now ‘Oh no, this sound like Scrum butt’. Maybe yes, but that’s ok. The reason is that in my opinion this simulation comes closest to the reality we find in many of today’s companies, which is often a hybrid between agile and waterfall, a ‘plugging in’ of the new into the old, a constant fight of agile teams dealing with traditional budgeting, governance and fixed scopes. This doesn’t mean it is an ideal state (this is why I prefer Lego4Scrum), but it’s closer to the reality and this simulation shows me that mixing waterfall and agile is very problematic (which is a good experience too!). If you want to do a Challenge of Egypt simulation, you will need a whole day. For more details, refer to this excellent experience blog post from my colleague Daniel Wolf.