Chapter 3: Product Planning

This topic is about the planning involved when you are building a product, or managing a whole portfolio of products/projects. We use a freeway analogy to get 4 main points across. This is a great topic to start a longer workshop with as you can then use the freeway analogy throughout the workshop.

Materials needed

  • coloured markers and pens for each table group
  • paper for each person
  • sticky notes

4Cs Training plan

Shout Out (C1)

Ask people to shout out answers to “What comes to mind when you think of a freeway and how traffic flows?” - if you like you can write these up as they shout out. This is a simple exercise to lead into the C2 teach.

You can ask questions like:

  • What happens when they widen freeways?
  • What if there is an ambulance?
  • How does car-pooling or bus lanes affect traffic?

Teach (C2)

To help people think about release and product planning we use a freeway analogy. It highlights two important concepts in agile planning: capacity and flow.

Velocity is a prediction, not a guarantee

When you travel on the freeway trying to get from home to work and there is an accident, what happens? For most people, the workday just continues and they slot in once they arrive at work. It’s an exception. You definitely don’t adjust your work commute to cater for an accident everyday, because most days there isn’t one. You also hopefully don’t work till 7pm just because you got in late.

In software teams this is the equivalent of a production issue or serious impediment that derails the sprint. It should happen as an exception, not an everyday event. When it does happen the velocity for that sprint will be less. That will impact how much you can get done in the sprint and in the release. That’s okay, but it means you need to adjust your release plans.

Some people have a misconception that teams MUST deliver a certain velocity, and that if they do not they should work overtime. If that’s the feeling in the room, try spend some time helping them see how this might impact things negatively.

Slide

More demand than capacity slows everything down

Think of a fully utilised freeway. What does that look like? Peak hour traffic uses every little bit of capacity on the freeway and it’s a big parking lot! The time it takes you to travel from A to B is long and frustrating.

As a city planner you would want to have the freeway in use, but also have the commute between A and B be a reasonable time. Thus, an optimised freeway has some space between cars, to allow for them to pick up some speed and travel the distance between A and B in a reasonable time.

In software terms this space is slack time. If the teams have every minute of their day booked against projects then they have no slack. No time to improve their process or figure out a new way of doing something. Instead they are probably context switching and just grinding out code with very little thought. If something goes wrong with a requirement, the team has no wiggle room to address that problem. This results in everything else either taking longer or in the team ignoring the problem.

Slide

It takes capacity to grow capacity

As a city planner you would realise that the freeway between A and B is used a lot and usually at full capacity. To make this flow better you need to widen the freeway and build an additional lane. Have you ever experienced this? What happens next is that traffic actually gets worse before it gets better, because the roadworks usually require one of the lanes to be closed while the new lane is being built.

In software terms this happens when you decide to grow your teams. It takes capacity to build capacity. New people need time from the experienced developers to get familiar with the domain and the code base. This takes up all of the new developers time and a lot of the current developers time. Thus their capacity goes down until the new developers are more comfortable. There are some ways to speed this up – pairing, hiring experienced developers – but even then, capacity will be decreased for a while.

Managers often add more people if capacity is not high enough, but they don’t realise this will actually reduce their capacity initially. If you need to grow capacity, make sure you can afford the lost capacity it will take to grow.

Slide

Optimise by prioritising high value traffic

Some freeways have bus lanes or lanes for commuters with 4 or more people in the vehicles. Essentially, this rewards car-pooling and public transport and punishes single person vehicles. On these freeways buses can drive much faster than the backed up normal lanes in traffic. Public transport users are rewarded with a much shorter travel time.

In software terms we might have certain work that is more important than other work, that we want to get done as quickly as possible. In agile there are mechanisms for dealing with this by reserving some of a teams capacity each sprint to deal with these issues. However, often people misuse this mechanism and end up prioritising low value items just because that stakeholder shouts the loudest. This is a bit like having a carpool lane reserved for blue cars. It doesn’t transport more people quickly, it just lets people in blue cars jump the queue.

Slide

Draw (C3)

Hand out paper to each person. Given these four examples, ask people to draw their freeway. Is it flowing fast, prioritising high value traffic, or blocked up with roadworks and 100% utilisation?

Write and share (C4)

Ask everyone to write down the point that is of most concern to them, and to share why with someone else in the room.