Can inflating balloons or folding paper hats really improve your development methodology?
Playing games is as old as mankind, and as civilization continues to develop and become more advanced, so do the games. In the past, people would play war games to improve their combat and strategizing skills, but nowadays we have agile software development methodology games! In this post, we will share our story of just one such game - XP game, which we recently played during one of our "Developers’ knowledge-sharing” occasions.
About the game
XP Game models the agile development process in a very funny and enjoyable way. Participating does not require programming skills - so not only developers, but managers, designers, and others can also take part in it. This is a perfect game for bringing the team together and learning something new about agile methods.
As you will see from our photos, we had lots of fun playing!
We highly recommend the game for other teams who would like to introduce agile methodology or for those who are already agile but want to experience the methodology from a different angle.
According to the manual, the entire game takes about 180 minutes. We didn’t believe it either...but it really does! So make sure you set aside enough time before you start.
As I was saying, XP Game models the agile development process: "The teams go through at least three XP 'iterations'. In each iteration, the team performs a game planning session (based on the given story cards) and an 'implementation' phase. Each correctly implemented story earns the team some 'business value'. The team with the most business value at the end wins.”
Team members and coaches alternate turns playing the role of Developers and Customers. Don't worry...it isn't as complicated as you think!
Time (minutes) |
Task |
Team member roles |
Coach roles |
|
5 |
Introductions |
|
|
|
20 |
Explain the concepts and the game |
|
|
|
40 |
Iteration 1 |
Estimation |
Developers |
Helper |
Planning |
Customers |
Helper |
||
Implementation and Acceptance tests |
Developers |
Customers |
||
25 |
Debriefing + introducing “velocity” |
|
|
|
25 |
Iteration 2 |
Estimation |
Developers |
Helper |
Planning |
Customers |
Helper |
||
Implementation and Acceptance tests |
Developers |
Customers |
||
15 |
Debriefing and discussion |
|
|
|
25 |
Iteration 3 + celebrating the winning team |
Estimation |
Developers |
Helper |
Planning |
Customers |
Helper |
||
Implementation and Acceptance tests |
Developers |
Customers |
||
25 |
Final debriefing and discussion |
|
|
Starting the game and the first iteration
To start, we formed 2 teams of 5 members each. Team members received pre-written “stories” from the Coach. (Story: a short description of a feature that, when implemented, will provide some value to the company.)
Developers estimate story complexity
First, the teams had to estimate the complexity of each task. They could choose a number between 1-6 or “impossible”. Then they had to sum up the complexity points they wanted to undertake in the 1st iteration, keeping in mind that the total time available for implementation is only 3 minutes!
Customers choose and prioritize stories to develop
Next came the Planning part: team members were "Customers” and they had to prioritize estimated stories and choose the ones to deliver. They had to keep in mind that the Customers’ purpose is to choose stories to reach the highest business value by taking into account business value/effort ratio. The result of the planning is the Iteration Plan.
Tough decisions
Developers implement stories
When the Iteration Plan was ready, they went back to the developer’s desk and started to implement tasks. The time for implementation is capped at 3 minutes, measured strictly by the coaches. When a story was ready, the timer was stopped for the acceptance process. If the story was accepted by the coach, they got the points and could continue implementing. The teams had to try to implement as many stories as possible within the 3 minute time frame.
Playing the Customer's role
Conclusions:
- The first iteration took much more time than we had expected, mainly because everyone was new to the game. Despite a strict cap of 3 minutes total for implementation, this phase took about 40 minutes in real time because of the multiple stops for the acceptance and review process for each developed story.
- Team members underestimated their productivity at first.
- At halftime of the first iteration they had a chance to re-estimate the Iteration Plan. This time they were more ambitious: everyone took on extra tasks, though one of the teams failed to complete them all!
Iterations 2 and 3
Introducing Velocity
VELOCITY = # of story points / iterations |
In the 2nd Iteration, there were some changes to the rules. The total points of all implemented stories became the team’s velocity. The Customer could only do his/her planning with this value as a baseline. Another new rule was that there was now a penalty of ½ a business value for unfinished planned stories, whereas unplanned stories which were fully completed were only worth ½ a business value. This made the accuracy of planning even more important.
Teams became more and more confident, but then came the 3rd Iteration! In the 3rd Iteration, after the first ready story the Customer came up with an unexpected but very important story which earns the highest business value of all the stories in the game.
Teams had to re-estimate their plans although they were now close to their maximum capacity.
One team replaced a planned story with the new one and the other team undertook the new story rather than the planned ones.
Implementing stories
Unexpected events can change everything
Conclusions
Finally, we held an evaluation where all participants could share their opinions. Here's a brief summary:
- We highly recommend this game! (Whether or not a team has ever used agile methodology)
- The game manual states that the entire game takes 180 minutes. We didn’t believe it either...but it really does! So you have to set aside the time.
- Estimations were based on time instead of the recommended complexity. It proved to be more effective to estimate stories based on short test measurements + the number of required people rather than the recommended method - of comparing stories.
- We didn’t really manage to change our points of view. We needed more time so that we could rotate to different roles. Some participants also suggested adding a Customer team of 1 or 2 members.
- Team members specialized during the implementation, just like in real life. But everyone chose a story or the stories in which they were the best...that’s why it would be interesting to see what happens if team members rotated roles during the game, for example in a 4th Iteration.
Try it if you are a software engineer team! Maybe we’ll also try it again soon.
Congratulations to the winning team!
More information about the game and its rules: