Want to be Agile? Then you can’t be Predictable! (or can you?)
Agility vs Predictability in Product Development
This week in Product Growth Leaders we discussed the tradeoffs between Predictability and Agility in Product Development. How do you manage predictability versus agility when making budgets and plans? This is a oft-discussed topic, and somehow managed to come up 3 times in very different contexts for me this week. It’s not easy, and it frequently depends on the kind of business you are in, and the culture you operate in.
My initial answer to the question was:
By planning different things and funding different things.
Don’t fund a project with a date, fund a team with a set of goals/problems to solve.
Change how you plan to be more “Now, next, future” and have varying levels of detail and certainty in those plans.
It’s non-trivial work to change an organization and their expectations to fit that, but you can develop small pieces of work iteratively in service of a larger goal, then release to customers when the entire org is ready and enough of the small pieces are bundled together to provide useful, marketable, and/or sellable value to customers.
Jason’s answer was pretty great — pointing out that the two concepts don’t need to be in complete opposition to each other and can be dealt with through communication.
However, the point Mike Cottmeyer makes here is super valid (and comprehensive) — you have to work within the org you are in, and meet them where they are. If they need predictability, the best thing you can do is reduce batch sizes, stabilize your teams, and start delivering with a constant velocity. Constant velocity = team level predictability. Then you can decompose big epics into smaller things, define them well, estimate them, and get a sense of when you will be able to deliver them. This starts to expand to be group or department level predictability over time. But you have to have a good backlog to be able to do that.
Stakeholder Management
Stakeholder management is also a big part of this — setting, meeting or adjusting expectations of your stakeholders as things change. Let them understand what is being worked on now, what will be next, and what’s after that. And you make sure to explain WHY those things are in the order they are in. You can have quarterly alignment meetings where this happens or do it another way. Basically saying “with what we know right now, here’s what we’re planning to do, but this can change. If it does, we’ll let you know what changed and why.”
It also helps to build slack into your schedule, especially prior to getting your teams delivering at a consistent pace. Building in a little buffer helps you under promise and over deliver (or to absorb the frequent unknown blips that come up without missing dates. Airlines do this all the time — when I was flying in and out of LaGuardia all the time. LGA to ATL is booked for 2 hours and 30 minutes, but the air time is much less. They build in buffer time for all the unknowns that come up both in the air and on the ground there.
In summary, build stable teams, plan for the unknown, be transparent and you will build trust with your stakeholders, and they will stop bothering you about predictability.
You can watch the recording here.
