The siren call of the BIG IMPORTANT THING

It’s easy for a multidisciplinary team – and everyone around them – to become myopically fixated on one BIG IMPORTANT THING and forget everything else. In my experience this looks like the team working hard, delivering the BIG IMPORTANT THING and making everyone happy.

Shortly after the celebration party, the team discovers that determining what happens next is difficult. This is usually because of one or more of the following:

• there hasn’t been time to do research on future features and options whilst focusing on the BIG IMPORTANT THING;
• there’s a mountain of technical debt or test cases to work on because of the need to deliver the BIG IMPORTANT THING too quickly;
• there’s a problem that needs to be sorted out because of an unexpected impact from the BIG IMPORTANT THING;
• everyone else is pressuring the team to immediately follow up the BIG IMPORTANT THING with ANOTHER BIG IMPORTANT THING, particularly if the BIG IMPORTANT THING didn’t deliver any benefits for them or altered the roadmap.

Pace and morale inevitably becomes disrupted at this point and regaining team equilibrium is hard. At best, this scenario brings a greater chance of friction, burn-out, argument, a fall in engagement and a decline in productivity. It’s going to be a lot less fun working in this team while you address these issues.

At worst, someone is going to suggest that the team carry on delivering whilst another team does their R+D work. That way, they will suggest, you get the ANOTHER BIG IMPORTANT THING sooner. Once that happens, you no longer have a multidisciplinary team. You will have two separate teams, and you will lose all the benefits of a collaborative, multidisciplinary agile team. With a barrier between the two teams, distrust can start to grow. (This is what we call waterfall: one team does the research and another writes the code.)

Prioritising product over project

What is the difference between a multidisciplinary team that can deliver the BIG IMPORTANT THING and a multidisciplinary team that can continuously evolve a product or service? I think the answer is constant pace.

Sponsors, developers and users should be able to maintain a constant pace indefinitely” – Agile manifesto principles

Constant pace doesn’t mean that a team keeps producing code. It means that it continually improves the service or product that it owns, to meet the changing needs of users, and it does this without having to stop or significantly slow down.

Stops or significant slow-downs can be caused by many reasons: you could run out of stories ready to be delivered, the team could be exhausted and low on morale, or you could need to do so much incident-handling or refactoring that you can’t do anything else.

Six ways to prioritise product and promote pace

1. Place equal importance on Discovery and Development work

Jeff Patton’s post on dual-track development suggests that discovery work is an essential part of the work of any team, and needs to happen alongside development work. (Discovery work here is defined as investigatory work: we’re not talking about the work typically undertaken in the discovery phase of the UK Government Service Standard.)

I agree with Jeff. If you want to maintain a constant pace, then you need constant discovery and constant delivery. That’s not to say that the percentage split in work between discovery and development tracks can’t vary; it is to say that they both need to continually take place. If you aren’t disciplined in doing this, that’s when you can get distracted by the BIG IMPORTANT THING.

Before I fully understood the dual-track approach, I was a big advocate of spike work but I occasionally let it slip because I implicitly valued development stories more highly than discovery stories. This was dangerous, because it meant that I reverted to a single-track approach in times of pressure.

Maintaining pace needs discovery and development. This means making safe space for your team to try new approaches, even – especially – when you have stakeholders banging on your door asking for their new features.

2. Trust and empower your product people

Product people should be responsible for the prioritisation of work in the team and for focusing on meeting user needs. They are not project managers responsible for the delivery of a BIG IMPORTANT THING; they are responsible for the continual iteration of their product. In Marty Cagan’s unforgettable definition, product people are missionaries and not mercenaries.

A product person is responsible for pace. If they’re not able or not allowed to manage pace, then you may get some short-term delivery gains but the long-term impacts will be significant. Uneven pace is going to make it difficult to manage roadmaps and it will confuse and disappoint everyone: team members, users, and stakeholders. It could break your team.

3. Feed your team a balanced diet of stories

If you’re serious about managing pace, then your product person needs to know what a balanced diet of stories for your team looks like. If you want to think about this, then the answers to these three questions should give you enough data to discuss this with your team at your next planning session:

• If you split the work in your last six iterations into discovery and development, what would it look like?
• If you split the work in your current backlog into discovery and development, what would that look like?
• If you came up with a perfect split between discovery and development, what would that be? (and how different is this to your answers to the first two questions?)

4. Monitor your balance by establishing guardrails

Once you have discussed what a healthy diet for your team looks like, you should decide how you are going to monitor this. How you do this will depend on your team, and I would suggest that you revisit this question at each lifecycle stage of the product or service you’re working on. For example:

• Do you need to ensure that there are equal, or specified, quantities of discovery and development stories in your backlog?
• Do you need to make sure that your ceremonies (planning sessions or show and tells) make time for considering both discovery and development stories?
• Is your delivery manager tracking the different types of stories delivered?

5. Make sure your stakeholders understand how you work

If you’ve discussed what a balanced diet looks like with your team, and determined what you’re going to do to ensure that you don’t depart too far from this path, there’s one more thing that you should do. This is to discuss your approach with your sponsors and stakeholders so that they understand why you work in this way. Doing this before you get challenged on your priorities will avoid awkward conversations later.

6. Be proactive about imbalance

Like any diet, it’s not the stopping that matters, it’s the returning to it that counts. If you detect an imbalance and decide to live with it for a short time period, it’s critical that you discuss with the team and your stakeholders what’s going to happen to enable the team to return to a healthy cadence and resolve the imbalance. This could include:

• asking another team to take on operational support for a sprint in return for your team returning the favour at a later date;
• a different approach to show and tells and communications;
• a “firebreak” (I get nervous about these becoming a sticking plaster for a team failing to maintain pace, so be careful you’re not papering over a bigger crack by doing this).

All of these options need careful planning to succeed. The time when a team decides to accept a short-term imbalance is the time to talk about these options, not later.

I hope these suggestions help you and your team. If you have any thoughts and suggestions, please add these in the comments. I’ve written some tips for handling discovery work in an earlier blog post.