On too many projects it’s easy to get caught in a debate about if we’ll deliver. There is some fixed point at which we’ll be judged—very likely a specific date—and when that happens we’ll look at what we’ve produced and see whether it matches our pre-defined threshold of “acceptable”.
If delivery of “acceptable” is in doubt then this is not a good conversation to be in. The pressure on the delivery team increases, and there is often talk about overtime. It’s not good for the external stakeholders, either—maybe they could increase the pressure, but usually they just end up feeling powerless.
It’s much better to be in a conversation about when we’ll deliver, and it’s possible to move from if to when more often than people think. To do this it helps first if we have a sense of value that is more continuous (“how much”) rather than binary (“whether”). I gave some examples in last week’s article about the value statement: reducing cost, increasing product visibility, decreasing our attrition rate among business users, and so on.
The next step is to structure the work so that we keep delivering to visibly improve on this value. Week by week we should see progress. For example, “We just changed Y to reduce our attrition rate among this particular segment of business users; next week we’ll be turning our attention to that segment of business users.”
As discussed a couple of weeks ago, a good product backlog is a sign we’re achieving this.
Then the conversations start to change, and become more positive for everyone. The delivery team continually returns to their stakeholders, always presenting the thing with newly-increased value. In the early days it’s primarily a demonstration of progress. But as time goes on the question can be asked about whether that’s enough. The more time that passes, and the more that gets delivered, the more urgent the question becomes: “Is this enough?” And “Given where we are in the timeline, should we go with this now while still continuing?” The conversation has shifted to when it’s time to release, go public, accept it’s enough, etc.
None of this changes hard problems into easy ones, or slow teams into fast ones. But it does ensure much more constructive conversations, and the relationship between the team and their stakeholders becomes more productive. The stakeholders become more able to help the team (for example, by steering priorities or challenging external demands), and all together the team and their stakeholders can be more confident about delivering the best possible outcome.
niksilver.com 