Why do we want to deliver fast, and then faster?
Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.
The second reason: time to market. In this context, I mean we need a good poduct to market before the opportunity goes away. Before the competition beats us there, or before the most important problem has changed.
Third. More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.
So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.
But there is more. We need to deliver faster because we get more feedback. In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.
This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero. So, we have minimized the potential loss in value of the WIP, the work-in-progress. We have reduced the risk.
All the reasons that make us want to deliver something faster.
Yes, it must be a minimum marketable feature set. But we are learning that 'minimum' is smaller than we thought.
Deliver faster. This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.
Then the question becomes: how do we do that?
Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.
The second reason: time to market. In this context, I mean we need a good poduct to market before the opportunity goes away. Before the competition beats us there, or before the most important problem has changed.
Third. More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.
So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.
But there is more. We need to deliver faster because we get more feedback. In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.
This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero. So, we have minimized the potential loss in value of the WIP, the work-in-progress. We have reduced the risk.
All the reasons that make us want to deliver something faster.
Yes, it must be a minimum marketable feature set. But we are learning that 'minimum' is smaller than we thought.
Deliver faster. This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.
Then the question becomes: how do we do that?
No comments:
Post a Comment