For a training on Scrum and Agile I was planning to give I was looking for games to play during the course to explain some basic things. Ofcourse we would be playing the XP game but I wanted something more to explain some other fundamentals.

One of the games I found interesting during my own trainings was Goldratt’s dice game. For the training I was preparing an adjusted version of Goldratt’s dice game. As you might know Goldratt’s dice game illustrates the effects on variation in processes and its effects on cycle time. You can find a simulation of it at http://www.ganesha.org/leading/toc.html.

Next to that I wanted to have another game to illustrate the effects of having large inventory and the difference between push and pull production. After a few minutes searching the web I found the CUPS game. (http://web.lemoyne.edu/~wright/cups.htm).

The Cups game is about the difference between push and pull production. It helps you illustrate its effects on inventory, costs, rework and ability to respond to change. One of the main things of being Agile is of course your ability to react to change and generate feedback, see http://cesarioramos.wordpress.com/2008/03/23/improper-feedback/.

I found that the outcomes of these games are easily related back to Lean and Scrum principles and that they can be used to have some fun and easily explain things during training.

How does Scrum relate to Goldratt’s dice game?
Using Goldratt’s game you illustrate that in order to maximize throughput you should minimize variation in processes. Scrum helps you achieve this by minimizing disruptions of work and achieving a sustainable pace throughout the project!. See also http://jeffsutherland.com/scrum/2007/07/origins-of-scrum.html

How does Scrum relate to the CUPS game?
The CUPS game helps you illustrate that we should limit work to capacity and keep inventory low if we want to be agile and effective. If not, your cycle time will go up and as a result your agility down! Scrum offers a way to limit work to capacity through its sprint planning. We know that during sprint planning the amount of selected work should be based on the team’s capacity.

There is also Little’s Law stating that WorkInProgress (WIP) = CycleTime (CT) * ThroughPut (TP). So to be able to respond quickly to change you should minimize the CT. We know that one way to achieve that is to minimize WIP. For a Scrum project you could say that the WIP is equal to the Sprint Backlog and the number of Product Backlog stories that are worked out in detail. So what is the minimum WIP that you should use? Again Scrum has some simple principles to help out. One of them being that we should focus on the top product backlog user stories the next sprint. So working on these and detailing them before the next sprint planning takes place is a good idea. How much work should be detailed? well… at least the team’s current capacity! I prefer to use the plan, do, check, adapt cycle. So I would first see how it goes with a WIP of about 2 times (sprint backlog and detailed stories on the product backlog) the team’s capacity and then take it from there.

If you want to have some extra fun during the CUPS game you could do so by changing requirements during the process.

Have fun!

Just last week a I witnessed again the great power of early feedback.

While starting up a small project I had several meetings with the overall project manager and several stakeholders discussing things like planning and needed resources. The project manager insisted that the work should be done within a certain time limit and that I should tell him the resources needed to deliver the project on time.

I gave him a idealistic planning based on his time limit and stated that after the first sprint a more accurate plan would be available. I requested several people to join the team and things like on site location, hardware for testing etc. Most of the requests were not fulfilled….
Read more →

I ran into some interesting problems when implementing some Scrummaging practices. One problem that I faced had to do with idle time of projects members.

The company I’m currently working for does its projects using the waterfall approach. The structure of the company supports the waterfall, the way of working of
the individual departments, their geographical locations, the strict separation of roles etc are all optimized for the ‘throw over the wall’ culture.
After some evangelism some managers got convinced to give Scrum a try on their projects. The projects had started about a year ago, but in that year they
had been working on architecture and requirement documents. So everything up till now was waterfall oriented. Funding was ‘fixed’, functionality was ‘fixed’, release date was ‘fixed’ etc. Now that we had the architecture and requirements we ‘only’ needed to build the system.

Read more →