I love being an agile trainer, mentor and coach. It provides regular insights into human behaviour that I personally find utterly fascinating.One of my favourite exercises that I use in Scrum Training is the Ball Game. It is a simple game and gives teams a wonderful opportunity to experience the power of self-organisation, frequent micro-planning and retrospection.
The objective is throughput of balls. You are one team. Each Sprint is 2 minutes with 1 minute for a retrospective in between. Each ball must pass through each team member’s hands at least once. Dropped balls are not counted. Each ball must have air-time and go up before it goes down You cannot pass a ball to someone directly to your left or right The end point must also be the start point. I start this exercise by simply putting the rules up on the wall. I then set up a big, highly visible timer for a 1 minute timebox.
There is total chaos. In the absence of someone telling them what to do there are many competing ideas about how the team might approach this task.
Often the Team reverts to command and control. The most dominant, noisy person tries to “take control” in the face of the impending timebox end and starts telling people what to do. I stand back and watch, fascinated.
After the one minute the planning timebox ends the Sprint starts. There is even more chaos but under pressure from the container (the timebox), the Team just have to start. Typically they don’t appreciate that it is better to just get on and deliver something, as opposed to standing around arguing about the perfect solution. They normally find this very difficult and this is where the pressure of the timebox kicks in. No manager is standing over them telling them what to do but the timer relentlessly counts down regardless.
At this point they typically look at the instructions again and respond by forming two straight lines facing each other. They start by person one throwing one ball at a time to person two (who is in the opposite line). Person two then throws the ball to person three who opposite them and beside person one. They throw the ball back and forth down the lines and one person at the end has to either batch the nearly-completed balls up and drop them back to the start or do it one at a time. At the end of the Sprint we count up the completed and the dropped (discarded) balls. I normally write this on the whiteboard for them to see. We then start the retrospective – 1 minute.
During this time they work together to figure out what worked, what didn’t worked and how they might improve. It is important that as their trainer I do not participate in this; they must self-organise. The first retrospective is normally hectic and confusing. The frustration of not performing to their best hangs in the air. They feel this team isn’t working as well as it could. However they are at this point only a group of individuals. There is no real trust or group norms yet and often this results in a range of different behaviours – from a dominant personality assuming the role of telling everyone what to do, to quieter folk not being prepared to say something, despite having very valuable input. Due to the strong desire for direction often they will simply try what the dominant personality suggests.
Typically the end of the timebox for the Retrospective suddenly looms. With seconds to go they realise they haven’t made any concrete decisions and that next Sprint is about to start. At this point someone will often say “let’s just try <idea>. We’re nearly out of time”. The retrospective time box ends and they are now onto Sprint Two. I record their decisions on the whiteboard and I set the timer for two minutes and inform them that Sprint Two has started.
In Sprint Two we often see the first signs of emergent order. They things they agreed to try from the previous retrospective typically have a positive impact. You can feel them starting to gel but there is often conflict (“he is such a useless thrower!”), roles (one person often acts as they person who starts and finishes the cycle of ball throwing), goals, standards and processes (“just slow down and do it properly guys”). This is what Tuckman called “storming”. It is healthy but often involves tension.
Sprint Two ends. We collect the data and review. Typically we have improved but there is a feeling that there is room for more improvement. The Sprint Two Retrospective starts.
If there is a dominant trying to take control the frustration levels in the team rise. They don’t like being told what to do, but equally haven’t found the courage or skills for constructive dissent yet. Quieter folks need to either find their voice of live with it. With more people having an input, management becomes decentralized and it is noisy. There are lots of suggestions but with their new found voices, nobody wants to now listen. Again, the time box helps guide this. At no point am I involved except to keep time. Rapid fire decisions start to happen. They just have to try something, or face the possibility of just doing the same Sprint again. Wastage starts to get eliminated. Progress!
In Sprint Three they typically start to find a rhythm. They joke with each other and relax a little as it is clear they are delivering more. They start to identity with each other and Team cohesiveness starts to develop.
When they review the results of the Sprint they sometimes notice their improvements are tailing off. We discuss what is happening. I usually say something like “often teams find that to break through a productivity frontier they have to have the courage for a complete change to their system”. I then shut up and start the timer for the Retrospective.
This Retrospective is often interesting and one of two things tend to happen. The Team either doesn’t have the courage to challenge the status quo, in which case they just press on, or they make some systemic changes. Often this will be reorganizing into a more optimal configuration, standing very close together or trying multiple balls.
If the Team made systemic changes then often chaos reappears. The familiarity of the previous system no longer exists. They are pioneering a new way and things don’t always go as they expect! If they didn’t have the courage to make change, Sprint Four is often a repeat of Sprint Three with a slight increase in throughput.
The Retrospective makes for interesting analysis. If they didn’t have the courage to change then the data will typically show that they are not really getting much improvement. If they did then they are probably worse off than previous! The “experiment” didn’t give them magic results. Damn! What should they do? Reverting back to the previous structure is tempting, however there is often a new found sense of courage and I have seldom seen teams do this. They discuss what they could do to address the issues with the new approach and press on. If they do this then this is often where the magic happens. They find a completely new level of productivity – a breakthrough that results in an entirely new productivity frontier. The unknown boundaries of the next frontier crate anticipation and electricity fills the room. They now have a sense that anything is possible.
The Team that didn’t have the courage to make systemic change often flat line even further. They butt up against the first productivity frontier. Addition effort will not yield sufficient additional outcome. Two unwelcome visitors set up camp in the team; disillusionment and it’s evil cousin complacency.
At the end of the series Sprints we reflect on the results. Often the attendees are stunned.
So what can we learn from this?
Firstly, Scrum highlights dysfunction. It doesn’t solve it. The true value comes from removing all the things preventing the team becoming incredible.
Secondly, if you want to break through a productivity frontier then you need to have the courage to challenge the status quo and be prepared to make systemic changes. Most workplace culture do not allow for this. It is not safe to fail. It is often downright dangerous.
Thirdly, Scrum uses the concept of a Container to control complexity. In this case the container was the time box, and it forced the Team to make a move – any move – upon which they could inspect and adapt, as opposed to more discussion, analysis and planning which would unlikely yield equivalent value.
Fourthly, for Complex work, evidence based self-management trumps centralised control and predictive management. Out of chaos comes order but we need to be prepared to remove the restrictions of traditional environments and have faith in our people to achieve this.
Fifthly, Agile values are critical; courage, transparency, integrity, faith in people, commitment. The leaders job is to create a safe working environment and demonstrate the behaviours as values in action.
And finally, Scrum is about the Art of the Possible.
I think about some of the teams I have worked with over the years. I recall being called into one organisation to help them figure out why Scrum wasn’t working for them. It didn’t take long to figure out. Their culture held “utilisation of resources” high. Management ensured that the Scrum teams always took on more work than was possible, just in case the team got through it more quickly than planned.
To help them move forward I took them through a visualisation exercise. I literally asked a room of 15 managers to close their eyes while I guided them through 2 minutes of “deep breathing” (I didn’t have the guts to call it meditation in case they freaked out). Once they were truly relaxed and their minds were no longer spinning in circles of “i need to do x, i need to do y…” I asked to them to imagine one of the team members. I asked them to imagine waking up in the morning being that team member. Imagine having coffee, eating breakfast, saying goodbye to loved ones and heading to work. What is the weather like? How do you travel to work? What do you notice? I asked them to make particular note of their feelings as they made their way to work and then arrival at their desk. What do they notice? At the end of the meditation I asked them to discuss how it felt working in that team. They all agreed – terrible.
Scrum has this incredible psychological effect built into it. We get transparency about what the organisation values and wants us to do. We get autonomy over how much work we pull into the Sprint and how we will design and deliver that. We deliver done, usable work in chunks of time no longer than one month. We get feedback on that work. We have a meeting dedicated to getting better as a team. And we can do that over and over.
As per the ball game shows, this can create incredible spirals of behaviour. When attendees look back on their progress at the end of the ball game they are often stunned at how much they improved over time and the camaraderie they developed as a team. And it was only a silly game throwing balls with no managers telling anyone what to do.
At no point did I ask them to deliver more. They wanted to and did everything they could to find a way to deliver more! On reflection they start to realise that anything is possible.
However, as per the “resource utilisation” example, behaviour spirals also occur in a downward pattern. When a team is forced to select more work that it can achieve, fails to achieve it, has to discuss its failure every iteration, has a retrospective realising that there is no point is trying anything as no matter what they do they are always going to have more work than they can achieve, then the feeling is one of complete and utter hopelessness and people give up. Engagement in the workplace is what we are trying to achieve and clearly this does the opposite.
So please – don’t just do Scrum. Think carefully about how it works, why it works and what your role is in helping. Create environments for success and watch them take on the world.