Well, can we?
There are some who do ‘waterfall’ (well, to be fair, something very roughly like the waterfall that Dr. Royce defined in 1970), and some of them seem to believe that we know enough early on, and change will be small enough for the rest of the effort, that we can promise a relatively precise date at the very beginning. And reliably hit it. And then, if we do not, they blame ‘scope creep.’
There are some in ‘agile’ (again, we must qualify it) who seem to think that change is always so large and we know so little up front, that we can never promise any release date for our product. Not at the beginning, and not even along the way.
Of course, we have to agree that the dumbest day of the project is Day 0, at the very beginning.
Next, let us first recognize how important an early release date is. It is very important to our customers, and it is often extremely important vis-a-vis competition and other factors. If we release earlier (eg, on time), then the present value of the business value we will earn will be greater (assuming other things roughly equal).
So, clearly there is a great need to release earlier. And, along with that, although arguably not as much in every case, a need to predict the release date earlier. And with reasonable accuracy.
Can we do that?
The short answer is yes, to some degree.
In Agile, we can do that, in my opinion, somewhat better than we did in waterfall. Which also means, still, not all that well on Day 0. We still have problems in predicting the future. We know the detailed requirements will change, in many ways and for several reasons. We know both good and bad change will happen. It does every time. The only question is how much things will change.
Still, after some time and experience and learning, we can make some prediction. And often, with a reasonable contingency, we can hit that date.
(I do not mean to suggest that the first attempt at predicting the date is accurate enough. That itself is an important business decision — when do we feel we are accurate enough? (after adding some contingency). Very good and difficult question.)
Can we predict ‘accurately enough’ every time? Of course not. And there are many reasons why. Sometimes we get hit with the ‘Japanese tsunami’ of change. A lot more change than we could have reasonably predicted. And then, usually, other people will fully understand if we do not deliver on time.
In another scenario, it is often not one piece of change, but the accumulation of multiple changes that overwhelms us as a Team. And, because it is not one big public change, but rather many factors, it is harder to understand from a distance.
Some situations are by nature more variable, subject to greater amounts of change (ex: subject to more learning about competition).
Still, even so, predicting, and using the information and learning we get from planning, can be very useful. It can give us a better basis from which to learn more, in many dimensions.
Finally, one more factor that must be managed well (and often is not).
We need sustainable pace.
First, it is a moral issue. We cannot treat people as slaves. Second, we must have sustainable pace because it will make things better. A pace that enables people to rest, and then, when they are working, to give their best creativity. So that the innovation is more impressive.
So, what is the problem? Well, we also know that people need some pressure, some challenge, to do their best work. And we also know that many many teams, if the deadlines are tight and people say ‘go fast’, the Team often hears that as ‘cut corners.’ In other words, build technical debt. Write sloppy code, let bugs in, do not document enough, do not refactor anything….and many more bad practices.
So, we the Team, we the Product Owners, we the managers, must be very careful in agreeing on dates and how we talk about this stuff. Or you will quickly have a buggy ‘legacy’ system, and everyone will resign from over-work.
And it is hard. You should (in my opinion), ask for dates and predictions. And the Team needs a challenge. But we must also talk about sustainable pace, about simplifying the work we do (smaller features), but NOT about cutting corners on quality. Or maybe better said as ‘still, what we do build, it will be of good technical excellence.’
I will not talk here and now of how we keep our promises. I have hinted already that breaking down the features and doing as little as necessary on the ‘big’ features is key. Fixing impediments is key. And identifying the minimum marketable feature set is key. And hence, making the right trade-offs is key. This includes cost-benefit trade-offs.
There is an art to doing the continuous research more effectively to make and revise ‘promises’.
And there is an art to working with the Team to change numerous factors so that we can improve the probability of keeping our promises.
People care about time. Tempus fugit.
There are some who do ‘waterfall’ (well, to be fair, something very roughly like the waterfall that Dr. Royce defined in 1970), and some of them seem to believe that we know enough early on, and change will be small enough for the rest of the effort, that we can promise a relatively precise date at the very beginning. And reliably hit it. And then, if we do not, they blame ‘scope creep.’
There are some in ‘agile’ (again, we must qualify it) who seem to think that change is always so large and we know so little up front, that we can never promise any release date for our product. Not at the beginning, and not even along the way.
Of course, we have to agree that the dumbest day of the project is Day 0, at the very beginning.
Next, let us first recognize how important an early release date is. It is very important to our customers, and it is often extremely important vis-a-vis competition and other factors. If we release earlier (eg, on time), then the present value of the business value we will earn will be greater (assuming other things roughly equal).
So, clearly there is a great need to release earlier. And, along with that, although arguably not as much in every case, a need to predict the release date earlier. And with reasonable accuracy.
Can we do that?
The short answer is yes, to some degree.
In Agile, we can do that, in my opinion, somewhat better than we did in waterfall. Which also means, still, not all that well on Day 0. We still have problems in predicting the future. We know the detailed requirements will change, in many ways and for several reasons. We know both good and bad change will happen. It does every time. The only question is how much things will change.
Still, after some time and experience and learning, we can make some prediction. And often, with a reasonable contingency, we can hit that date.
(I do not mean to suggest that the first attempt at predicting the date is accurate enough. That itself is an important business decision — when do we feel we are accurate enough? (after adding some contingency). Very good and difficult question.)
Can we predict ‘accurately enough’ every time? Of course not. And there are many reasons why. Sometimes we get hit with the ‘Japanese tsunami’ of change. A lot more change than we could have reasonably predicted. And then, usually, other people will fully understand if we do not deliver on time.
In another scenario, it is often not one piece of change, but the accumulation of multiple changes that overwhelms us as a Team. And, because it is not one big public change, but rather many factors, it is harder to understand from a distance.
Some situations are by nature more variable, subject to greater amounts of change (ex: subject to more learning about competition).
Still, even so, predicting, and using the information and learning we get from planning, can be very useful. It can give us a better basis from which to learn more, in many dimensions.
Finally, one more factor that must be managed well (and often is not).
We need sustainable pace.
First, it is a moral issue. We cannot treat people as slaves. Second, we must have sustainable pace because it will make things better. A pace that enables people to rest, and then, when they are working, to give their best creativity. So that the innovation is more impressive.
So, what is the problem? Well, we also know that people need some pressure, some challenge, to do their best work. And we also know that many many teams, if the deadlines are tight and people say ‘go fast’, the Team often hears that as ‘cut corners.’ In other words, build technical debt. Write sloppy code, let bugs in, do not document enough, do not refactor anything….and many more bad practices.
So, we the Team, we the Product Owners, we the managers, must be very careful in agreeing on dates and how we talk about this stuff. Or you will quickly have a buggy ‘legacy’ system, and everyone will resign from over-work.
And it is hard. You should (in my opinion), ask for dates and predictions. And the Team needs a challenge. But we must also talk about sustainable pace, about simplifying the work we do (smaller features), but NOT about cutting corners on quality. Or maybe better said as ‘still, what we do build, it will be of good technical excellence.’
I will not talk here and now of how we keep our promises. I have hinted already that breaking down the features and doing as little as necessary on the ‘big’ features is key. Fixing impediments is key. And identifying the minimum marketable feature set is key. And hence, making the right trade-offs is key. This includes cost-benefit trade-offs.
There is an art to doing the continuous research more effectively to make and revise ‘promises’.
And there is an art to working with the Team to change numerous factors so that we can improve the probability of keeping our promises.
People care about time. Tempus fugit.
