Coaching and Training
- Also some Useful Tools
Note that we have some Incomplete Pages That Require Work on this site:-)
Note that we have some Incomplete Pages That Require Work on this site:-)
I have no idea where the “Ball Point” game came from but I learned about it from Bob Schatz. Since learning about it I have found a great game to help people understand (by doing) what it means to execute in an agile (Scrum) way.
I introduce the game by saying “Whether you knew this or not, when you came to work today you actually came to work in our 'Ball Point' factory. Your 'ball point' team is everyone in the room. Work consist of passing the ball around from person to person, passing through each person until the ball gets back to the start point. When this happens, you record a 'ball point'. Your purpose in life is to generate as many 'ball points' as you can.”
I then go through the set of “rules of the game” per the slide:
And explain the basic mechanics of the game.
“You will be given:
Does everyone understand. OK go - 2 minutes until you have to provide me with your first estimate.
Oh, and by the way, 'no tools' is another rule. You cannot just put all the balls in a bag and pass the balls around that way.”
An area big enough for everyone in the room to participate in a rough circle.
A box of about 20 balls.
Something to time each 60 sec and 2 minute period
A flip chart / whiteboard as follows:
I find it easiest to be the scribe and time-keeper for the game. I just use a countdown timer on my phone and write results up on the board as we go. I also take notes as the game progresses based on what I see and hear.
Things will seem chaotic at first. Just remind them of the 2 minute time box for an estimate at the appropriate time. Then force the estimate, and get the group to do the first iteration.
People will try to second guess themselves and you. You will be asked things like “is someone opposite me a neighbor” and so on. Answer the game ones as quickly as you can, and as often as not by pointing to the rules of the game with a comment “its your process …”
Try to make sure that the estimate provided is a “team” view, not just whoever spoke first or the loudest. This will help with team accept the results.
In the first sprint watch for teams not counting completion correctly, or failing to count at all. You don't want to have an argument so if they have a number jot it down, and then put what you thought the number was beside. Another area that might be useful for debrief.
After the 3 sprint I typically make the following statement “You know when I did this with another group (perhaps name something) they were able to produce <a big number of ball points> … just saying” I calculate the <big number> by multiplying the current “actual” by 2.5 or 3 and a bit (don't want to make it too obvious). Be careful how to phrase this - you don't want to push a “stretch goal”, just provide the information.
One of the interesting things about this simulation is that there is a lot can be shown and talked about as a result. This is what makes a great exercise, but it also means that you should be selective about what is highlighted, partially lead by what the group raises up but also, as a coach / trainer, you might have a couple of ideas in mind. In particular, do not try to do all these messages, just focus on 2 or 3 key ideas.
To start the conversation you might want to start with something open ended:
You can then guide the remainder of the debrief around the remaining points depending on what you noticed, team interest, and time.
Let's look at a typical set of results that you will get out of this game and look at things we might see.
What do we see?
Other things (perhaps a little more subtle) that can be talked about include:
What we set up with this exercise is a cadence. When people started the exercise it felt chaotic. How did we become less chaotic? Well we knew we had to do something in 2 mins. And then we knew it was 60 seconds like, then another 2 minutes and so on. In other words the cadence functioned as an organizing principle for the group. This is useful to remember no matter what flavor agile you use. For example, Kanban can benefit from regularly scheduled planning, demos and retrospectives, even though this is not a formal part of Kanban.
In most organizations teams will say “management have unrealistic expectations on the plan”. Management will say “but we asked the team for their estimates …” Agile tells us that the traditional estimating approach has a number of problems but the people at the team level are also responsible for some of this.
If you look at the chart of results from the expectation of a manger watching the team what we see sprint by sprint is
In other words, in 5 sprints, we only made and met commitments once. How is a manager to view this. What is really sad is that we had a 23X improvement in productivity, but from a planning perspective we have set bad expectations.
Where did these expectations come from? The team. Disregarding the first estimate at the moment, look at the behavior for the remaining estimates. After the first sprint we know we can produce 1 ball point. But what did we tell management (me) we could do? 7! After 10, we said 15. Why wouldn't we just say the estimate is “whatever we produced last time”? If we do this and we get a better than expected result, this is usually seen as great news. This type of estimating is called “yesterday's weather” - in the absence of any other facts, best guess for today's whether is whatever it was yesterday:
This helps set expectations based on reality, not fantasy.
Even though we understand agile principles of feedback, experiments, incremental approaches, etc conceptually we often have trouble recognizing when we should apply them. For example, in the ball game an “experiment” to find out how many balls we could do before providing an estimate might have been useful. And most teams don't understand how rapidly incremental improvements build to really impressive results (23X improvement in productivity) as it is often hard to see unless you step back a little.
The game shows the application of the scientific method or Demings PDCA cycles - you put a plan or experiment together with an expected set of results, you then do something, you check the results and make adjustments (or determine the next experiment to). All agile approaches incorporate these cycles.
A little difficult given that the only way to play this game is when everyone is in the room, but perhaps a question “how would you have done these improvements if your retrospective was done online, or across multiple time zones”. Often teams have remote people, so this is just a reminder that most retrospectives with remote people should include a discussion about how to improve team communication.
This is the opposite of the theory of constraints. Ask “what if we did have a professional basketball player on this team, someone who is way better than anyone else. Would it have helped us improve productivity.” Since the whole system determines the result, the answer is “no” unless we had the team learn from the expert and thereby improve the capability of the whole team.
Most teams settle down on a process and eventually that process does not improve as rapidly as it once did. In other words, for this way of working, there is going to be a basic ability to “produce” a kind of “natural velocity” for the process as it stands. Often you will find teams will decided to do something very different in order to improve (sometimes as a result of hearing that some other team is “better”). Most of the time the experiment does not work as well as anticipating resulting in the same or less ball points than they had before, but most teams decide they want to continue with their new approach.
The lessons here are:
Close the conversation by asking about application to their work - what might they change?
And then I usually finish the discussion with a “Do you know what you have done? You have just done agile - all the rest is details:-)”
A slightly meta point, but may be interesting for some, this is a good example of emergent behavior as a result of complex systems. You will find that, if you run this a number of times, that there won’t be the same soliton coming out for any group although there will be a lot of similar patterns. The emergent behavior is a result of constraints, boundaries, and focusing.