We’ve all done it, it’s the most normal thing in the world, asking “when” something will be done. After all it’s a pretty important question to ask. You need to know when something’s going to be ready, because you need the thing you’re asking about. You wouldn’t be asking otherwise, right?
Let’s take an example we can all understand.
You’re on a road trip with some friends. You’re sat in the back of the car. The weather is good and the traffic is clear. You ask your friend that’s driving:
“how long till we get there?”
your friend answers
“a couple more hours, if we don’t have to stop and the traffic stays like this”.
Simple eh, easy as; you take your estimated distance left to ‘there’, the speed you’re travelling and you give an estimate.
Easy as pie. With Agile or Scrum that example is a lot like ‘velocity’. The driver just gave you a sort of burn-down estimate to ‘there’.
Now imagine a slightly different scenario, for the purpose of keeping it simple we’ll stick with the car theme but change some other environmental variables. This time you’re in a race. You’re Lewis Hamilton and you’re driving an F1 race car.
“I need to know when you’re going to overtake the Ferrari”
Your team boss get’s on the radio to you as you’re racing, it’s lap 10 of 80.
Bill – Team boss:
“Hi Lewis, how’s it going? I need to know when you’re going to overtake the Ferrari and if you’ll win the race?”
Lewis answers:
“errrrrr… can you repeat that?”
Imagine how Lewis Hamilton would react to those questions. They’re questions he can’t answer. As much as he would love to know himself. Think about all the assumptions and unknowns in those questions. Think about how different it is to the road trip example. Think about whether Bill cares about all the assumptions and unknowns in his questions.
It’s likely no F1 boss would ever ask a driver that kind of thing, but some Product Managers and Scrum teams get asked those kind of questions every day (metaphorically speaking).
Let’s break down where I’m going with this and why I’m taking about it.
“Asking ‘When?’ is the easiest question you can ask. (ask instead why you have to)”
Asking ‘When’ is much easier than ‘How?’ and even easier than ‘Why?’. When most people ask ‘When’ they want an absolute. A date and or a time. Absolutes are easier to understand. There’s no debate and not much else to discuss or remember. You do not have to be a rocket scientist to ask for a ‘When?’.
However, you do sometimes have to be one to answer. Particularly if you’re being asked “When will the rocket launch be?”…
Generally speaking, “When?” questions are either simple or hard to answer. There is little in-between. If the answer to Bills F1-race question was simple, it’s unlikely he would even ask it. So we have to presume the answer is likely to be hard to produce. That puts the focus of effort on Lewis Hamilton, since he’s doing all the work and Bill is just asking a question.
Let’s take the metaphorical F1 question and translate it into a real world question that an Agile team might be asked, this time Bill is a Programme Manager at a software company producing digital stuff and Dave is a Scrum Master. The Scrum Team have just got together and they’re not sure of their velocity yet, like wise the scope of the mobile app isn’t clear either:
‘Hi Dave (SM), it’s Bill(PM), I need to know when you’re going to release the new mobile app, and can you tell me what day the Widget feature will be complete? I just need a range for my plan.’
Bill is basically asking for what many stakeholders & Project Managers love to ask Scrum teams for, a couple of release dates.
Let’s focus on a role to help us understand why ‘When’ is important. Project & Programme Managers largely manage risk and organise activities into plans and deliverables, it’s a tricky job for certain. Spending all day coordinating people, customers and resources to enable things to happen successfully, ideally on time and on budget so everyones happy. So everyone gets paid. It’s totally understandable for them to need to ask for dates and times – the ‘When’ questions. It’s the nature of the role.
“these plans become an inaccurate overhead, a burden that no one trusts”
Now all that would be fine had both Dave (Scrum Master) and Bill (Programme Manager) not signed up to an Agile methodology to deliver their products. Long range planning is not something Agile does particularly well, it’s not really meant to.
So those big old Project plans with all those dates that have been pressured out of teams by asking the wrong ‘When’ questions, they’re not really all that important. They’re artefacts from bygone waterfall days. Now since they’re using Agile, these plans become an inaccurate overhead, a burden that no one trusts.
Although since they’re now using Scrum the news to any stakeholders seeking the ‘when’ in terms of release dates is good! The premise of Agile is incremental, frequent releases. Scope is prioritised and estimated and as velocity becomes stable, it becomes easier to understand how much effort remains – i.e. a Burn down. This means there’s no big bang releases of old. Stakeholders come along with Product Owners to Sprint Reviews, progress is visible and obvious. Scope is flexible and Product Owners can prioritise new features if they have to. They’re able to do the kind of things with Agile that would render any waterfall plan inflexible and inaccurate. So since the Agile process is transparent and flexible there’s an obvious lesser need for ‘plans’ and those ‘when dates’. Yippee!
… and this is the critical point, in this ‘new’ world, the ‘When?’ question is over taken by the ‘What?’.
“The ability to adapt is more valuable than the ability to plan at distance.”
‘What?’ is our scope and that’s way more important than the ‘When’ as Agile is about delivering the most valuable features the soonest and at regular intervals. The ‘When?’ becomes easier, because releases are more frequent and predictable. Much like Lewis Hamilton, Dave would struggle to tell his Programme Manager when a totally new feature is going to be released, because that’s happening on lap 60 in the future, and they’ve not got to that point yet. There are too many unknowns along the way, just like there are in the race car. The ability to adapt is more valuable than the ability to plan at distance.
“build a culture that thinks about the What before the When”
So in summary, my advice is to build a team culture that thinks about the What before it thinks about the When. Instead of thinking about deadlines, think about effort remaining. Let the ‘When’ emerge as a by-product of your process. There are numerous techniques and processes we can use to understand when something will arrive, but great Products are about building the ‘What’ that customers want, and delivering it a such a way that we can do it quickly and with least overhead.
“great Products are about building the ‘What’ that customers want”
If your customers are stuck in a world of delivery deadlines, then take them on a journey of enlightenment! Every soul in your organisation needs to fully understand why you use ‘Agile’ and help customers and stakeholders comprehend it’s benefits.
Sometimes focusing on the ‘When’ is a distraction for Agile teams, fixed scope deadlines almost always end in failure, burn out or poor quality.
So think about the Why and the What – if you do that right you won’t have to worry about the When.
by
Rob Horan