The transition of teams to agile is always challenging. People have expectations, habits, and beliefs about Agile.
We worked with teams they were saying We are agile already. Because we are time boxed.
Well, yes, you are right. Partially. The agile means a much wider range of practices. An agile coach can explain principles in nice looking presentation. That works. Partially. People see, but they do not buy in. Mostly because they miss real life experience.
We’ve decided to use practical approach by playing the game called Drawing game. We see the same results for more than two years and hundreds of people. It works. Therefore we suggest it to you. Especially if you are the coach, trainer or scrum master. Or the manager who would like to improve teams.
Drawing game rules
- Self-organize into teams
- In every team, there must be analysts and drawers. No specific number, it is team’s decision who is who.
- No voice communication between analysts and drawers. Just paper as an analysis.
- The coach will show the picture just to analysts.
- Analysts need to describe it in any written form, any language. No drawing, just sentences, characters.
- 10 minutes per round (per every picture) with a result at the end.
- 5 minutes discussion for improvements identification. What was done well in the round, what can be improved and how?
We typically ask to draw three pictures, starting with the simplest to some abstract picture (see pictures).
Example of pictures
This picture is simple by intent. Most of the teams are successful with it, but anyway you can find differences in finished drawing. Analysts used to spend 80% for writing a precise analysis of the picture, while drawers have free time. It is nice to be a developer as you have 80% of the free time.
As a coach, you should check the way how team distributes work among team members. Check if they are not doing waterfall. In 99% of cases, they will do waterfall. Write on a board the time when analysts returned back to the team and re-check this time in later rounds.
The second round teams used to send more analysts to solve problem of not completed drawing because analysts spent 80% of time in the first round. The result in second round is not good as well in 40%-50%. Analysts need to self-organize work of picture analysis. And there is an obstacle on the picture, ellipse in the center. They need to agree who is going to draw it.
Typical round progress is that teams start to work in increments/iterations. They draw shapes and not sides of the picture – an example of feature thinking.
The last picture is very hard to draw. In two years only two teams decided to draw it and they were pretty good at it. The reason to do this picture is to ask a question:
"Which picture is similar to software development? First, second or third? Why are you applying all these techniques while drawing pictures and not while developing complex systems?
What your people learn by playing this game:
- Incremental development
- Iterative development
- Documented analysis results vs. communication with a customer/analyst
- Self-organization of the team
- Leadership vs. Management
- Early feedback
- Changes are welcome
- Time box
- Result driven work
- Retrospective/Process improvements