I have just started reading the book Applying UML and Patterns by Craig Larman. I find it very interesting because it challenges many of what I have been told at work. I read that requirements aren't fully collected in one go in agile and it takes many iterations to complete requirements gathering. If that is the case, is putting up a hard set deadline, which is what I'm forced to do at work, very un-agile, considering there could be some new ground breaking requirement (or change request masquerading as requirement) tomorrow?
Asked
Active
Viewed 662 times
4 Answers
20
There's absolutely no "Agile" problem with having a fixed release date if you're prepared to move one of the other two edges of the "iron triangle": the requirements for what needs to be in that release, or the resources you have available. You can't fix all three - and in practice, the "resources" side of the triangle is very often either not very flexible or inefficient to modify.
If there's a major new requirement tomorrow, that's fine so long as the business is prepared to accept that requirement might not make the release date - i.e. it slips to the next release.
Philip Kendall
- 26,027
3
I think the problem in many Agile camps is with the word deadline. The risk with a deadline is that you assume you know what needs to be done. As you point out, you can't have a deadline for an unknown.
What is described in Philip's answer is far less a deadline than a constraint. We could say that we have funding until March and so we must make the best product possible in that time.
To give an analogy, let's suppose I ask you to go to the grocery story and buy all of the groceries for the week and, before you go or look at any prices, I want you to tell me exactly what you will spend. Further, you'll be penalized if you are wrong. You'll do exactly what people do with project deadlines - you'll pick a number at the high end of what you think the range might be because it has the lowest chance of you getting penalized. Now, let us say I tell you this is unacceptable and you must buy the same things you planned, but you must do it for $50 cheaper, or else. Now what can you do? You can refuse, you can just postpone the argument until after you shop, or you can find a way to cheat the situation. This is what happens in many organizations with deadlines set on unknowns.
Now, seeing how unhealthy this whole situation is, Agile just says "If you have a budget, I can promise to come in under that and will give you the best meals possible for this week in that constraint." Which is a far healthier conversation to have.
Daniel
- 2,039
2
Agile is a technique, not an outcome. Comparing to lawn-mowing, one iteration is like one line of grass that you have mowed. If someone says "mow your entire lawn in 15 minutes", and you are using agile, perhaps you will complete 30% by the end. Then you will iterate some more later and finish it.
Dingo
- 21
2
You can have a planned release date with no problem. Just make sure that at this particular date you have no lose ends. You should have a product that could be shipped at the end of every sprint, but usually there is no harm done if you don't; it's more a goal that focuses the work instead of a requirement. If you have a planned release date, then you must have a releasable product at that date.
You usually will aim to have an untested, but hopefully releasable product some time before the planned release date, then the product is tested and bugs fixed until quality standards are met, and then it is released without any panic needed. The release will contain whatever was ready at that time.
Now it may not be obvious to your boss that you should plan a second release date as well, with more features actually implemented.
gnasher729
- 49,096