Timeline for Dealing with failed sprints and deadlines
Current License: CC BY-SA 3.0
33 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 29, 2016 at 22:28 | comment | added | Doc Brown | @Dunk: since your company did not go not bancrupt so far, I guess the situation you experience has nothing much to do with the example of the question. You envision far too much of your own situation into my comments ;-) | |
| Feb 29, 2016 at 22:23 | comment | added | Dunk | @DocBrown - People love to blame management but in this case, I don't agree. The developers said 3 weeks. Management gave them more time, not much more, but more time. I can't recall the last time I've ever had that happen too me. Usually, management halves my estimates and then the customer halves them again:( Blame management in those cases, but they never get blamed, the developers always take the blame for being too slow or not working long enough hours. Thus, my estimates now take those tendencies into account and everyone ends up happy. | |
| Feb 29, 2016 at 13:35 | comment | added | Doc Brown | @Dunk: I was not aware where I wrote any sarcastic comments here. And yes, customers will always try to fix, time, scope and money (which is quite understandable from their point of view). But they are not to blame for this. The failure happens when your management agrees to such a contract without big enough safety margins, and without doing an active management of the development activities. | |
| Feb 26, 2016 at 17:36 | comment | added | Dunk | @DocBrown - That's fair. I was jumping in on your tit-for-tat comments pointing out "sarcastically" that different domains have different kinds of customers and scope is frequently not negotiable. Normally it is either time or money that is fixed along with scope in my domains. I think you both have different kinds of customers and that is where disagreement lies. I agree that it was management failure to believe that a production worthy product can be delivered in 1 month unless there's already a working product with just a few tweaks needed. Especially if the expertise isn't already in house | |
| Feb 26, 2016 at 17:24 | comment | added | Dunk | @gbjbaanb - I know people don't believe it but companies that successfully use Waterfall do many of the same things that "Agile" takes credit for doing. And they were doing it many years before "Agile" even existed. Nobody who successfully uses Waterfall does one step at a time like Waterfall implies. There's overlap, iteration, multiple builds etc..Waterfall is just a guide that is loosely followed. There's really not a lot of "new" things that the "agile" movement has brought to the table, unless you want to count adding more useless meetings and unacceptable work conditions. | |
| Feb 26, 2016 at 17:19 | comment | added | Doc Brown | @Dunk: if you have read my answer carefully, you might have noticed that I did not write fixing time, scope and money in a contract would be a management failure on its own. | |
| Feb 26, 2016 at 17:12 | comment | added | Dunk | I guess my entire career has been based on "clear management failure". I can't recall ever working on a project where "time or cost" and "scope" weren't explicitly called out in our contracts. I take that back, if we are developing "in-house" applications then it was more of a what you can get done in the specified time-frame. But external customers, I have obviously been working for the wrong management as we agree to deliver exactly what the customer asks for. I guess I have a character flaw because I prefer to deliver all of what the customer wants instead of just some of it:( | |
| Feb 26, 2016 at 12:34 | comment | added | Doc Brown | @Cronax: my point is: the situation described in the OPs question is a clear management failure - the so-called "deadline" (including fixed, unrealistic time and scope) is a cause of a bad contract and missed opportunities. Euphoric states something different - he says you cannot work agile when the customer refuses, it is all the customer's fault. and better do not work for such customers. Where I agree to this point is: do not make contracts with customers when they insist on "all-or-nothing", but do not be astonished when after you agreed to such a contract the customer insists on it. | |
| Feb 26, 2016 at 12:12 | history | edited | Pete | CC BY-SA 3.0 | The name is not the "Agile Manifesto" - agile is an adjective, and it is the software development that is agile, not the manifesto |
| Feb 26, 2016 at 11:11 | comment | added | Cronax | the Cambridge dictionary makes this even clearer: "a time or day by which something must be done". Unless your definition of done somehow specifies that tasks don't actually have to be completed to be done and the customer has agreed with that definition of done, you will be expected to deliver 100% of all the features. | |
| Feb 26, 2016 at 11:07 | comment | added | Cronax | @DocBrown @EricKing What you are talking about is not a time limit but a time box. If the scope is not fixed and instead you are committing to "seeing what you can get done within 3 weeks" then it isn't a deadline but a time-box. The very definition of a deadline is the requirement of having task X done by time Y. The Oxford dictionary defines a deadline as The latest time or date by which something should be completed, not as 'The latest time or date by which something should be at least partially comzpleted and the work will be stopped anyway' | |
| Feb 26, 2016 at 9:42 | comment | added | Doc Brown | @EricKing: thanks, that is my understanding of that term, in general, too. However. my understanding of the specific "deadline situation" described by the OP is somewhere between what you described and what Euphoric insists to be "the one and only correct interpretation". To my understanding, it is a situation where end date and feature list are fixed into a contract by mismanagement, and not because "the customer does not accept agility". | |
| Feb 26, 2016 at 0:45 | comment | added | Eric King | I agree with Doc Brown here. You can absolutely have a "time limit" without saying exactly "for what". It's perfectly reasonable to say, for instance, "Our deadline is <some date>. On that date, we'll ship what we have done." The scope of what gets shipped does not have to be set in stone the moment the deadline is created. Agile development is all about managing scope and communicating progress inside time-boxed increments, which are all actually mini-deadlines of their own. | |
| Feb 25, 2016 at 12:28 | comment | added | Euphoric | @DocBrown Again, I'm repeating myself. You cannot say "time limit" and don't say "for what". You just CANNOT say just time limit with time. You HAVE to say for what task or objective that time limit applies. You must live in some different universe if you think "time limit" means something different in agile and in waterfall. | |
| Feb 25, 2016 at 12:10 | comment | added | Doc Brown | @Euphoric: of course "deadline" means "finish X by Y", but with a much stronger focus on "time limit" than on everything else. Where I agree to you; if a potential customer wants not only to fix the deadline in time, but also wants to fix scope and money to unrealistic expectations, then it may be better not to sign a contract at all. Nevertheless "deadlines" (=time limits) work IMHO well with "agile". | |
| Feb 25, 2016 at 11:54 | comment | added | Euphoric | @DocBrown Clear definitions are important in communication. And you cannot just make up your own to fit your own worldview. Pretty much everyone and their mother defines deadline as "finish X by Y". I have yet to meet a person who only thinks of deadline as "time Y" with no task X associated with it. | |
| Feb 25, 2016 at 11:52 | comment | added | Doc Brown | @Euphoric: yeah; I am clearly wrong, since I did not pick the interpretation you like best ;-) | |
| Feb 25, 2016 at 11:48 | comment | added | Euphoric | @DocBrown Wrong : "promises to ship the software in 1 month". Here "ship the software" means "all features are implemented". So yes, here deadline means "promise to implement all features in 1 month". Also, the very definition of Time limit is "particular point in time, by which an objective or task must be accomplished". You cannot have a deadline without clearly defined "objective or task". | |
| Feb 25, 2016 at 11:45 | comment | added | Doc Brown | @Euphoric: the OP was clearly using the term "deadline" for the time, so were I. And the fact one has the ability to adjust scope or money to some degree does not mean those are not defined. | |
| Feb 25, 2016 at 10:20 | comment | added | Euphoric | @DocBrown If scope or money are not defined, then I wouldn't consider that a deadline. Deadline says what should be done when. If you can adjust what will be finished by deadline, then that is not really a deadline. | |
| Feb 25, 2016 at 10:13 | comment | added | Doc Brown | "find better customers" is IMHO the wrong answer, I strongly disagree that you cannot combine "Agile" with deadlines. Quite the opposite - agile approaches give you much more control to adjust scope or money when the time is fixed. | |
| Feb 25, 2016 at 10:12 | history | edited | Robbie Dee | CC BY-SA 3.0 | added 1 character in body |
| Feb 25, 2016 at 9:42 | comment | added | gbjbaanb | @RemcoGerlich ah, I think you misunderstand my point: in that agile is not really about the dev methods, but the ability to get on with the work, using whatever means you like. Its about progress not procedures after all. (eg a team that only does Scrum is not agile, a team that only does waterfall-style but modifies it to suit circumstances is) | |
| Feb 25, 2016 at 9:35 | comment | added | RemcoGerlich | @gbjbaanb: Any 3 week project (that finishes successfully within 5) is going to look like it was remarkably agile. | |
| Feb 25, 2016 at 9:31 | comment | added | gbjbaanb | @RemcoGerlich ironically, "let's decide what needs to be done and do it" is remarkably agile itself :-) | |
| Feb 25, 2016 at 9:25 | comment | added | RemcoGerlich | @RubberDuck: The project is already not-agile, because the requirements are set in stone. And the estimate is only three weeks. There is nothing magically bad about waterfall that makes it always late, it just can't deal with vague requirements and change. Yeah, I would use "waterfall" in this case, or more accurately "let's decide what needs to be done and do it". | |
| Feb 25, 2016 at 9:06 | comment | added | RubberDuck | @Euphoric scope or time, pick one. =;)- | |
| Feb 25, 2016 at 9:05 | comment | added | Euphoric | @RubberDuck There has yet to be a software project management methodology that allows features to be decided up front, deadline set and was not terribly expensive. Scope, Time, Money; Pick two. | |
| Feb 25, 2016 at 9:02 | comment | added | RubberDuck | @RemcoGerlich would you really suggest waterfall for it? That would only make the project even later. | |
| Feb 25, 2016 at 8:58 | comment | added | RemcoGerlich | This. If the project is in no way agile (100% of features mentioned in the contract that was written up front, needed on deadline day) then an agile method shouldn't be used for it. | |
| Feb 25, 2016 at 8:48 | comment | added | Euphoric | @RubberDuck Basically. I did see people claiming about having contracts that said "At end of each iteration, we present what was agreed at start of the iteration and will get paid if customer accepts." With no mention of deadlines or features needed to be implemented. | |
| Feb 25, 2016 at 8:36 | comment | added | RubberDuck | Possibly not the client's fault, but the legal & sales teams for writing/accepting stupid contracts. | |
| Feb 25, 2016 at 8:31 | history | answered | Euphoric | CC BY-SA 3.0 |