The nature of our work means we’re not unfamiliar with joining projects that are struggling, or in danger of doing so (with a view to turning things around of course!).

Often in these situations, I’ve noticed agile being blamed as the reason for failure within the wider business. But where things aren’t going to plan, it’s often down to these common mistakes in implementing agile:

• Stakeholders other than the product owner telling the team what to work on
• A backlog which is not well organised, and without enough features ready to play
• Unnecessary constraints put on the team
• Little focus on getting something shipped all the way to production and adding value to the user

None of these problems are the fault of agile; they are down to failures in the team’s execution of delivery.

The problem is really that it’s hard to know what good agile development looks like, if you haven’t experienced it before – even if you already buy into the principles of agile.

That’s why I’ve come to love the Ball Point Game, invented by Boris Gloger (thanks Boris!). It’s a great way to helping people understand common delivery problems, and it has become a staple for me to use within the first few weeks at a new client.

Although the game is mainly intended to teach people the basics around scrum, I use it to highlight the specific problems I noted above, and it really helps people understand how those problems could affect them.

Let’s go through the problems I identified and show how this versatile little game can increase understanding of each one:

1) Stakeholders other than the product owner telling the team what to work on

During the game iteration I spend a lot of time throwing balls (representing features) at people in the middle of working. Unsurprisingly, this disrupts their flow and makes them drop features (balls) already in progress. It highlights to the team what a distraction it is to receive unexpected demands, and the dramatic impact they have on velocity.

I’ll then run the exercise again but only pass the extra balls to the product owner. This may still have a little impact, but you can see it’s nothing like the effect it has when throwing them at the team. And it’s easy to then go a step further – showing how there is no impact on velocity at all if new features/balls are put into the bucket that the Product Owner takes from (representing the backlog).

2) A backlog which is not well organised, and without enough features ready to play

In this run of the game, as the Product Owner is busy taking balls out of the bucket, I spend my time emptying the bucket all over the floor (repeatedly). As well as entertaining me, it demonstrates the time it takes to get a backlog in a good enough state to be ready to feed the team with new work. It also shows the impact of not having the backlog ready, as the team is soon stood around with no features to work on.

What I see quite commonly here is that although the product owner starts with a full bucket, most of the time they don’t feel the need to keep filling it back to the very top – as long as there are enough balls in there to keep the team moving, it’s all good.

At the end of the iteration I ask the product owners why they don’t treat their own backlogs in the same way. It’s quite common for less experienced product owners to feel they need to scope the entire project upfront. This exercise helps to show them that this isn’t the case – they can start realising value for users without knowing how many features their project will eventually end up with.

3) Unnecessary constraints put on a team

Running the game once again, this time I ask the team to put one hand behind their back and to use only their left hand. With most players being right handed, it slows the team down a lot.

The point here is to show what impact unnecessary constraints have on a team. Why should they use only one hand? Why can’t they use two hands if it makes it easier! If it makes no sense, it should be challenged.

I then take things a step further and ask the team to re-review the original rules of the game with me, to discuss what other rules they can change. By asking them to run the game again with the change in rules, everyone understands how much more effective the team is.

4) Little focus on getting something shipped all the way to production and adding value to the user

A key problem that is very, very common is a lack of focus on getting something finished all the way to production. When the infrastructure to create an automated pipeline to production isn’t in place, a team will tend to declare their work ‘done’ when the development of a feature is complete, but it’s of no use to anyone until it’s in users’ hands.

This problem is very easy to demonstrate with the Ball Point Game. A ball isn’t able to add value until it is in the done bucket. So I just remove the done bucket. Without a production state and something for our users to get value from, there is no ‘done’.

What’s more, every single one of those balls will need to go back through the team again to ensure the work is complete when the pipeline is finally in place.

This exercise highlights so many issues; the double handling of the same work, the additional time it taken to realise value, and the constraints the team have to work under.

Try the game yourself

Even if you do know what good looks like, the Ball Point Game is a great exercise to help pass the knowledge on.

It’s so versatile – as well as the problems I’ve shared here, it can also be used to demonstrate the difference between scrum and Kanban, the impact of scaling agile, and what the impact of a change management process can have on delivering value (something for a future part two).

If you’re interested in seeing the game in action, keep an eye on your nearest ExpertTalks meetup group. I’ve already run a session in Leeds recently, and I’m planning to take it to Cardiff, Brighton, and Manchester in future. If you’re new to agile, or working with someone who is and want a useful way to pass on knowledge of best delivery practices, do join us.