11

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?

Kaushik
  • 219
  • 1
  • 3

4 Answers4

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
  • 22,899
  • 9
  • 58
  • 61
  • 1
    I’ve always felt that that resource side of the triangle is a mistake. Swap it for quality and it works better. But you are spot on: tie me to a release date if you must but features and quality will slip as a result. – David Arno Feb 10 '19 at 19:22
  • 1
    @DavidArno I'd argue that "quality" is part of the Definition of Done, which is itself part of every requirement. And "resource" certainly can have a significant impact on delivery if you take resource *away* from the project. – Philip Kendall Feb 10 '19 at 19:39
  • In other words: in order for "agile" to work, you have to spend a lot of money, spend a lot of time or sacrifice quality :) – Christian Hackl Feb 11 '19 at 08:38
  • 1
    @ChristianHackl: I think no matter what the methodology, software development requires a lot of time and a lot of money if you also want quality. – Bryan Oakley Feb 11 '19 at 14:53
  • @David: I would argue that there is a right level of quality. Cutting corners on that level will nearly always end in problems and exceeding the appropriate level of quality will always be waste. – Daniel Feb 11 '19 at 16:24
  • 2
    @BryanOakley: That's true. I just wish agile evangelists would actually recognise that their methodologies aren't special in this regard. Once you leave behind the false assumption that agile lets you have your cake and eat it, then you can actually design the correct development process for your project by choosing if and how much "agile" should be in it. – Christian Hackl Feb 11 '19 at 16:55
  • 1
    @ChristianHackl No methodology is a silver bullet. But the main point of "agile" (a broad term) is not that it should make the successful deliveries cheaper/faster but that it keeps the cost of (inevitable) failures down. – Guran Feb 12 '19 at 07:39
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,041
  • 8
  • 12
  • You actually *promise* that to people? What if you are wrong and another approach would meet the deadline with even better meals? – Christian Hackl Feb 11 '19 at 17:29
  • 1
    Similar arguments about Agile and deadlines [here](https://softwareengineering.stackexchange.com/questions/274203/are-deadlines-agile) – Eric King Feb 11 '19 at 20:11
  • @Christian. Sure. At the least, it is the best I can deliver within that constraint. Perhaps someone else could do better or perhaps if circumstances were different I would have come up with a better solution, but those speculations don't seem valuable. Especially considering that I always have more information the later in the project it gets, any estimated deadline I give now will be, by its nature, less informed than anything I tell you later. – Daniel Feb 11 '19 at 22:03
  • of course, we're talking about a fairly complex topic on the StackExchange platform, which isn't designed to handle broad multi-faceted topics. I tried to keep my answer concise and focused to meet the platform. It is, in fact, a very narrow slice and much can be said about the more robust nature of software development and organizing the development lifecycle. – Daniel Feb 11 '19 at 22:26
  • @Daniel: Well, I just object to the notion that one *promises* ideal results to a customer just because you believe you use the best approach. That's not realistic. – Christian Hackl Feb 12 '19 at 05:55
  • @Christian - that's a fair comment. In a real-life conversation, it is far more nuanced than that. – Daniel Feb 12 '19 at 14:01
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
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
  • 42,090
  • 4
  • 59
  • 119