111

For clarity, a deadline is:

A time limit or deadline is a narrow field of time, or particular point in time, by which an objective or task must be accomplished.

From wikipedia

My whole software development career I have been doing "Agile" which everywhere has seemed to mean at least the following practices were adhered to:

  • Weekly or Bi-Weekly sprints
  • Retrospectives Sprint planning
  • A product owner
  • Scrum
  • User Stories

However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?

My own opinion is that they are not, as I see deadlines leading to a lack of flexibility and lack of quality. Instead, I think it provides more value to focus on Sprints and early deliveries. It seems however, in every circle I have been in, this is not the case, and deadlines are viewed to go hand in hand with Agile development.

stevebot
  • 2,003
  • 2
  • 16
  • 19
  • 37
    Isn't as sprint a deadline? – JeffO Feb 23 '15 at 20:34
  • 13
    @JeffO a Sprint is a commitment, which shifts based on the velocity of your team. Deadlines are IMO, commitments without honesty or transparency to the client. They do not take into account velocity or the multitude of other risks that go into making software projects. – stevebot Feb 23 '15 at 20:42
  • 2
    Are you saying you periodically have your clients review the software after a sprint, but they have no idea how long it will take nor what functionality to expect? I get future sprints are adjusted based on previous sprints and may have more accuracy, but your next sprint has a deadline with an expectation of certain functionality. – JeffO Feb 23 '15 at 20:55
  • 2
    @JeffO I am saying Sprints are based on estimated work and my teams velocity. I can give my client an estimated date based on my teams velocity for when a feature should be done. THAT is transparency and that is Agile. – stevebot Feb 23 '15 at 21:00
  • Sprints shouldn't have "estimated dates". Sprints should be pre-defined time-boxes. What gets accomplished _during each sprint_ may vary, but the sprints' durations shouldn't. – Eric King Feb 23 '15 at 21:04
  • 2
    @EricKing I never said sprints have estimated dates. Work that is estimated, along with my teams velocity implies that certain planned features will likely be done on an estimated date. – stevebot Feb 23 '15 at 21:10
  • 8
    I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes nothing from the old "cost/time/scope" constraint idea, it simply uses scope as the preferred method of managing slippage on the basis that better prioritization against scope is generally preferable to spending more money or time. – Calphool Feb 23 '15 at 21:26
  • @Calphool Care to write an answer? Your comment is insightful and is adding a POV which I do not see in the other answers. – stevebot Feb 23 '15 at 21:38
  • Added below. :-) – Calphool Feb 23 '15 at 21:41
  • 9
    Here's Ron Jeffries' (one of the original authors of the Agile Manifesto) take on deadlines: http://xprogramming.com/articles/jatmakingthedate/ – Jules Feb 23 '15 at 23:38
  • 3
    Note that "Agile" usually encompasses more methods/practices than just Scrum (for example Extreme Programming and Kanban). It just irks me when people think Agile=Scrum. – sleske Feb 24 '15 at 14:40
  • What irks me is when we pretend that Scrum isn't *primarily* how agile is implemented in industry. Ever been to a conference? Seen them ask which methodologies people are using? Scrum gets 95% of the crowd. Kanban = dumbed-down Scrum. XP is *primarily* engineering practices, and doesn't tell you much about how to manage the lifecycle. That leaves Scrum as the primary means of implementing agile. Yes, agile is technically a way of thinking, scrum is technically an implementation of that way of thinking. However, agile *itself* is an implementation of Lean. It's turtles all the way down. – Calphool Feb 24 '15 at 18:55
  • @Calphool I would substitute Scrum with [Scrumbut](https://www.scrum.org/scrumbut). I don't think I've ever met a team that claims to be using Scrum that _actually_ does Scrum, by the book. :-) – Eric King Feb 24 '15 at 21:09
  • There are some teams that manage to implement it more-or-less fully. It requires a lot of management buy in though. – Calphool Feb 24 '15 at 21:16
  • 2
    Aren't semantics wonderful, everyone? Whether something is "Agile" is not what you should be focusing on. Just because you label something doesn't make it a bad or good idea. Focus on **having a realistic, successful workflow for developing your software**. If the practices under the "Agile" label work for your team, wonderful; use them. If not, deviate from the label and do what works. And be willing to change your process as the team learns from past mistakes. (Really, that last one is as "agile" as you can get.) – jpmc26 Feb 25 '15 at 00:37
  • 5
    Some of my deadlines have proved pretty agile. – psr Feb 25 '15 at 21:39
  • There are some good ideas in this writing: https://stackoverflow.com/a/1144723/908336 – Masood Khaari Jul 06 '16 at 07:29
  • @JeffO It can`t when it`s based on estimations...Then you cheat yourself if you believe you can deliver at the right day. – Pascal Nov 10 '16 at 18:52
  • @Pascal - That's why it's called an estimate. If you're working on a project that has a must be completed by date for a very large set of fixed features determined at the very beginning of the project, why bother being agile? Do a few sprints and reevaluate either the due date or what features you estimate may get done. In reality, that's the best you can do. – JeffO Dec 06 '16 at 01:05
  • Sprints are deadlines. What's not agile is a required delivery date AND a required set of functionality. – Rob Crawford Nov 05 '18 at 21:04

15 Answers15

157

Deadlines are a reality. Most times you have to have something by a certain date. It's unavoidable. Without deadlines, even agile projects can succumb to Parkinson's Law:

Work expands so as to fill the time available for its completion.

In other words, if your project can go on forever, it will.

In relation to deadlines, Agile tries to do a few things:

  • Ensure that everybody can always see how much work will get done by the deadline
  • Ensure that the most important features are completed first
  • Ensure that the completed features are usable, in the sense that they don't depend on features that haven't yet been completed
  • Ensure that development continues at a sustainable pace

That way, when the inevitable day comes, you don't have a useless pile of code, but a working, tested product with, hopefully, only the least important stuff unfinished. And nobody is surprised by the finished product.

So yes. "Agile" and "deadlines" can be perfectly compatible.

Eric King
  • 10,876
  • 3
  • 41
  • 55
  • 1
    I would think though that have planned sprints negates Parkinson's law? If all the work is planned, and you are focused on making your Sprints, then there isn't any available unplanned time for work to expand into. – stevebot Feb 23 '15 at 20:24
  • @stevebot Sure, but how many sprints do you have? Do they just go on indefinitely? – Eric King Feb 23 '15 at 20:25
  • 1
    No, Sprint's are planned around the delivery of features. Once the client agrees there are no more features to complete, there are no more sprints. – stevebot Feb 23 '15 at 20:28
  • 10
    @stevebot That's exactly the situation that prompts Parkinson's Law. I've never met a client that can't think of more features to add. Without deadlines, the feature list, and thus the project, is infinite. – Eric King Feb 23 '15 at 20:30
  • 2
    @stevebot Sometimes the deadline is budget-related. The client only has so much to spend, which translates to so much time. There's your deadline. Now, let's fit in as much as is practical, starting with the most important. – Eric King Feb 23 '15 at 20:31
  • Right, but you can imagine agreeing to deliver features 1-10 in build 1.0, and features 11-20 in 1.1, right? This way the sprints for build 1.0 end when the client agrees that features 1-10 are complete. If they don't have enough budget for this, then we should be able to detect that maybe at Sprint 5 based on our velocity. IMO, deadlines are always a moving target, even when we say they aren't OR its a deathmarch to the finish with a POS product at the end. – stevebot Feb 23 '15 at 20:37
  • 1
    Never ending sprints is the consultant's dream. Never ending billable hours... –  Feb 23 '15 at 20:43
  • 3
    @stevebot Perhaps we're defining deadlines differently, then. If it's a "moving target", then it's not a deadline, by definition. I've worked on many projects that function like you describe: v1.1 is done when it's done. But occasionally you have a hard date by which something has to ship. In that case, the feature list is what becomes the moving target. That doesn't make your project less "agile". – Eric King Feb 23 '15 at 20:44
  • @MichaelT Indeed. :-) – Eric King Feb 23 '15 at 20:44
  • 1
    @EricKing which then suggests that one should glance at the demographics of the agile manifesto signers and their role/profession. Just saying... –  Feb 23 '15 at 20:47
  • @EricKing A deadline I would define as "X feature by X date" if you have to take our X feature, then you have by my definition missed the deadline, and would have been just as better off using Sprints and transparency then commiting to "X feature by X date" – stevebot Feb 23 '15 at 20:48
  • @stevebot Ok, that's where we differ in our understanding of the term. To me a deadline is a date. Period. As in "We've got to ship by the end of Q3 this year". Tying a specific date to a specific set of features is, I would agree, probably anti-agile. – Eric King Feb 23 '15 at 20:52
  • @EricKing But what if you make that commitment and based on your velocity you can't even ship any features? My point is that even a deadline that is "just a date" has some feature set requirements, and can be missed. – stevebot Feb 23 '15 at 20:59
  • @stevebot You're not getting what I mean by deadline. Its a _date_. You can't "miss it", because it's on the calendar. The "agile" way is to ensure that when that date comes, you've worked on and tested the most important stuff, because _what you have is what you release_. – Eric King Feb 23 '15 at 21:01
  • @EricKing you are not getting what I am saying. A deadline is never "just a date". Notice you tacked on the caveat that "you've worked on and tested the most important stuff" = a commitment to at least one or more features. – stevebot Feb 23 '15 at 21:11
  • 12
    @stevebot I think we understand each other, but have different meanings of the word "deadline". To me, a "deadline" is a specific date. To you, a "deadline" is a specific set of features promised on a specific date. I believe my definition is the more common usage, and my answer is based on that definition. Judging by the other answers you've received, others agree with me. Take it for what you will, I won't be offended. :-) But my answer still stands. – Eric King Feb 23 '15 at 21:17
  • 1
    @EricKing I understand but I think you and others are mislead in thinking that a deadline can be "just a date". (especially in the eyes of a client) There will always be expectations and its always possible that your teams velocity causes you to miss the most basic of features. – stevebot Feb 23 '15 at 21:24
  • 5
    " There will always be expectations and its always possible that your teams velocity causes you to miss the most basic of features." If you're implementing agile properly, then that statement is an absurdity. Your backlog *MUST* be prioritized according to maximum customer value. If it's not, *FOR WHATEVER REASON*, then you're not practicing agile. You're practicing something else. – Calphool Feb 23 '15 at 22:36
  • 1
    @Calphool: The backlog only needs to be prioritized for high-priority items. The bottom of the backlog typically contains things whose exact priority doesn't matter yet. "Could become interesting as the market matures" may end up as "Looked like a good idea back then". Agile is efficient because you avoid doing work that has a risk of becoming irrelevant. – MSalters Feb 24 '15 at 00:15
  • 1
    This doesn't actually answer the question. Boulders exist but aren't part of agile, and deadlines exist, that doesn't make them part of agile. – djechlin Feb 24 '15 at 03:04
  • @djechlin Agile development teams acknowledge, accept, and adapt to the reality of deadlines. That's what this answer is about. – Eric King Feb 24 '15 at 03:12
  • 2
    @EricKing they also eat and drink, but that's not part of agile either. It might be more accurate to say "deadlines are out of scope of agile, but ideally agile teams don't miss deadlines." Or, explain what agile principles lead to deadlines being met effectively. etc. – djechlin Feb 24 '15 at 03:20
  • 2
    A deadline can't be "just a date". If it was it would be called a "date" rather than a deadline. We have at least 28 of those every month, but sometimes no deadlines. – bdsl Feb 24 '15 at 14:49
  • 7
    "We have to have something to ship by the 28th of July." The _deadline_ in this sentence is the 28th of July. You can have the "something" be a predetermined set of requirements, or it can be whatever is ready. The "something" part is not the deadline. The _date_ is the deadline. – Eric King Feb 24 '15 at 15:10
  • 2
    Wikipedia says about Parkinson: "He derived the dictum from his extensive experience in the British Civil Service." In my experience in *private* industry, the only reason work expands if given more time is that corners no longer have to be cut. I've heard managers talk about "gold-plating", but I've never seen a project where that happened; *rust-plating* is more the order of the day. – Kyralessa Feb 24 '15 at 16:27
  • @MSalters: I didn't say anything about "prioritizing the *entire* backlog" as you seemed to suggest. I said: "Your backlog MUST be prioritized *according to maximum customer value.*" – Calphool Feb 24 '15 at 18:11
  • 1
    I still don't agree with this answer. Yes, Agile can work with deadlines, but are deadlines Agile? This is never answered directly. Also, a deadline being just a date goes against every definition of deadline, and as @bdsl mentioned you might as well just say "date" – stevebot Feb 24 '15 at 21:29
  • and while I accept some of the answer, I think it lacks information and misleads the reader to believe that Agile + Deadlines = perfectly fine. The truth is they _can_ place nice together, but it takes effort and the application of certain principles to met that deadline as @djechlin is on to. – stevebot Feb 24 '15 at 21:35
  • 1
    @EricKing The entire sentence is the deadline. If that sentence or something like it hasn't been said by a relevant person then there is no deadline. – bdsl Feb 24 '15 at 21:36
  • also it misinforms the reader that Agile cannot work without deadlines. This is not true, Agile when broken out into feature sprints can work fine without a deadline, and still gives the Customer an estimated date of completion without any dishonesty. – stevebot Feb 24 '15 at 21:42
  • 5
    @stevebot "(The answer) misleads the reader to believe that Agile + Deadlines = perfectly fine." That's the point, though. Agile *is* perfectly fine with deadlines. Or without. Take your pick. To say otherwise is basically saying "Well, since we have a deadline, we can't do this project as agile!" which is baloney. I've worked on many projects that have both had deadlines and have been "agile". Are deadlines agile? Well, they're not _not_ agile. – Eric King Feb 24 '15 at 22:03
  • Most recently, my team (although not me personally) worked on an application that had to be ready in time for the Super Bowl. That was an absolute deadline. The project was done in a perfectly agile manner, with the understanding that what we had by the deadline is what we'd be using. There was absolutely no conflict between "having a deadline" and "agile project". – Eric King Feb 24 '15 at 22:25
  • @EricKing thanks, I see your point, though it took me awhile. they're not _not_ agile. – stevebot Feb 24 '15 at 22:26
  • @Calphool this fails Ockham's razor. It would mean you've also seen projects where the developers successfully negotiated enough time, didn't cut corners and finished a day early. Yet no matter how developers estimate, the project is delivered just barely. – djechlin Feb 24 '15 at 22:27
  • Eric, the sentence "deadlines are not *not* agile" is very effective. Your answer is good but taken as a direct response to the question title sounds like it's saying "deadlines are agile," which is obviously contentious (and I disagree with as I voiced above). You might consider being explicit here. – djechlin Feb 24 '15 at 22:28
  • @djechlin: Sorry, what are you talking about? – Calphool Feb 24 '15 at 22:29
  • My bad. @Kyralessa ^ see my above – djechlin Feb 24 '15 at 22:31
  • 5
    -1 for citing Parkinson's Law as though it is actually true. Despite its popularity, it was written by a humorist and is not backed by research. See Peopleware by DeMarco and Lister for a great explanation of this topic. – Planky Jan 28 '16 at 03:15
  • @Planky Thanks for mentioning about the fallacy of Parkinson's Law. Peopleware is a must-read for those interested in the topic. – Masood Khaari Jul 06 '16 at 07:33
  • While I agree with your point. However, a deadline is agile-less. If you follow a pattern (agile) and you break with it, then you are not following it at all (obvious). Agile preaches "freedom", well... then it's not a pattern at all (pattern for not to say ideology). – magallanes May 18 '18 at 03:21
  • Note: Definition of Done (or MVP) is a prerequisite for Deadline to have meaning, otherwise a Deadline is simply another name for 'A Date'. My understanding is that for agile sprints, the date is nearly always fixed, but the in scope / done at SprintEndDate is fluid. – Kristian H May 18 '18 at 13:19
  • "Work expands so as to fill the time available for its completion. In other words, if your project can go on forever, it will.": But this is simply not true. At least, my experience is that I move on to something new when I do not see any meaningful tasks to be done for my current project. – Giorgio Nov 05 '18 at 17:08
  • I might have to agree with @stevebot, a deadline where you deliver nothing is not a deadline. You have to deliver something of value to satisfy the client on that date, that's a deadline. Which means that it is entirely banking on the fact that things were estimated properly for that to even be achieved within the timeframe that was set, and that the development happened as planned, and the necessary resources were put behind it, etc. Agile is a good way for development to go smoothly, so it is better at hitting a deadline then other methods, but I don't see deadlines as a part of agile. – Didier A. Apr 08 '21 at 19:14
  • Dear lord if I had a quarter for every question I asked on SE that got closed because it was only fractionally as opinionated as this one, I'd be rich. At the very least the discussion here proves that the answer is inadequate. The pragmatic definition for deadline is quantity promised on date. But there's a third factor: The quantity and/or date are unreasonable. That's why they're "dead"lines. I've never seen a reasonable deadline. They all require crunch and cutting corners. "dates" are unknown quantities at specific times. Those are more "Agile" to me, because we deliver what we can. – void.pointer Jul 06 '21 at 17:20
  • Delivery date, quantity of features, code quality. Choose any 2. – void.pointer Jul 06 '21 at 17:20
27

Deadlines are a fact of life. There are things that have a very firm date.

We need the software by Comdex

or

The games must be on store shelves by Black Friday

and the like. One cannot postpone Comdex or Black Friday - the rest of the world doesn't work that way.

The goal that Agile has is that things that won't meet the deadline fail faster (and that is a good thing), or the scope is able to be re-examined sooner so that the resources can be focused on the correct ROI in a more timely manner.

The deadline is a hard date that is set down firmly. Agile is a tool that allows one to realize earlier in the cycle that the software is going to take twice as long to develop as originally hoped. It is important for project managers to be able to realize these issues earlier than later so that either more resources can be added, the scope changed, the deadline adjusted (in the situation where it is a firm rather than rock solid deadline) or the project canceled.

The transparency that Agile seeks is that of showing the problems and progress earlier in the cycle. The classic waterfall delivery failure is one were you've spent months behind closed doors and deliver the product a week before the deadline and are told you're doing it all wrong and you've wasted months (and now have completely blown the deadline). The other classic waterfall failure is finding out a week before the deadline you've still got months to go. Agile seeks to make these issues known early in the process.

The other part that Agile seeks to do in the context of a deadline is that even if only part of the agreed upon features are complete (for whatever reason), the current version of the software is useful and deployable.

Ok, we missed having everything we want for the tax software to be deployed on April 15th, but we've got 75% and what we do have works and has been working since we started last November. We've known we are not going to be able to deploy the full feature set since mid December and refocused our efforts on the 80% of the customer base.

  • 2
    I agree with you, though I would flip the importance of your two assertions. #1. Agile is *primarily* focused on making sure that the current version of the software is useful and deployable. #2. Secondarily, it helps us realize when scope is completely unreasonable earlier so that product owners can reprioritize and maintain the goal of #1. – Calphool Feb 24 '15 at 18:31
  • 2
    @user40980 This is horrific. Yes, there are things that have a firm date. however, you cannot produce an infinite amount of work in a finite amount of time. Deadlines can't be Agile *except* when they're only produced after estimation. That's an extremely important caveat. That's why you plan a sprint -- to determine exactly what work can be completed. A hard, fixed deadline by which everything must be complete in spite of effort cannot EVER be Agile. – EKW Jul 04 '16 at 19:14
20

Some deadlines must be met. Contractual obligations, conventions, regulatory requirements. Some are imposed by managers who want to be able to put software development in the same chart as manufacturing on their spreadsheet. Whatever the cause, most people can't get away from them.

If you are working in a functioning team then communication between the developers and management/stakeholders means that the people who need to make a decision are well informed to decide if missing the deadline or continuing with development is more important.

Even if you are delivering completed user stories once a week, or twice a month you will still probably have deadlines. When one is coming up, make sure your stakeholders know what you think will fit in by the deadline and set expectations.

If you are constantly building the best software you can with the requirements you currently have at every stage, then a deadline at the end of any sprint should theoretically not be a problem. Practically, this isn't normally the case, but then neither are deadlines that appear out of thin air. Most important deadlines I've ever been given were communicated to me long before, it was the expectation of the quality and the features that were the issue. All the deadlines I can think of that have come out of nowhere are because of lies. Either sales told a customer the feature was there or could be added without consulting and sometimes without even informing engineering, or someone told their boss it had already been done.

Encaitar
  • 3,053
  • 19
  • 26
16

If someone wants to set a deadline then that is fine and the deadline can be fixed, but what they must understand is that if the deadline is fixed, then the scope must remain flexible.

tl;dr

In an ideal world we wouldn't have deadlines and just deliver things when they are ready. The reality though is that people paying for things usually want to know when they are done. Agile methodologies do recognise this but also recognise that not everything can be tied down.

This ensures that you can keep quality of delivery at the level that is right for the product. If you fix a deadline and scope (and budget) then things get rushed and you end up back in the old waterfall world with a crazy crunch time at the end of the project. Increasing the budget usually isn't the answer, because adding more developers and testers doesn't solve a problem faster. It's a well-known view (and I agree with it from experience), that the more people you add (each with their own foibles) the more time it takes.

Now, typically (unless they really understand Agile methods) the person paying for the software doesn't like being told, we can meet your deadline but we can't do everything you want. This can be managed by prioritising the features that make up the software. Your prioritisation discussion might go like:

Dev Team (D): "Please can you prioritise the features you want delivered, with most important first?"

Customer (C): "Everything is priority 1 - I want them all done by the end of next month."

D: "That may be possible, but that may not be possible if requirements change or we discover issues we didn't expect while going through development."

C: "Well what if I give you more money?"

D: "sigh...even with more resource it's going to take them one month to really get going; so if you're not sure how to prioritise the features just tell us which ones you want done first."

C: "Ok I want the big button but make it really big, and then ...etc"

Now you can start working through the features in priority order. It does help to also look ahead with your team to those items lower in the priority order and make some early estimates, knowing you may change them when you get to development when you have more information. This can be used to redefine or create your roadmap if you don't have one yet. This then forms the basis of your release plan. The roadmap can be discussed with the customer acknowledging that scope may change but you do have an order of things to be delivered.

One of the great advantages of Agile is that it acknowledges that things change as you go through development and you adjust as they do. Contrary to more traditional approaches, this principle, in conjunction with the regular sprint deliverables and ongoing communication with the customer, mean that you are naturally forced to be more transparent about progress, which is a good thing.

Sometimes the customer doesn't like that they will not get what they want by a certain date BUT they will understand why and what they do get will be of good quality. And 6 months after features are delivered the customer won't care or remember that you delivered by a certain date, they'll remember the quality of the product that they are still using.

Community
  • 1
br3w5
  • 719
  • 2
  • 6
  • 12
  • 10
    "So if someone wants to set a deadline then that is fine and the deadline can be fixed, but what they must understand is that if the deadline is fixed, then the scope must remain flexible." Absolutely. – Eric King Feb 23 '15 at 21:05
  • 3
    This is probably the most agile answer on here. The fact that it doesn’t have many votes is testament to how widely misunderstood agile is. – PostCodeism Nov 18 '18 at 09:51
15

Arbitrary deadlines that have no consequences if missed aren't very agile, but there are situations where for reasons outside of the development team's control deadlines must be set and kept. Fortunately, if the deadlines are reasonable there are plenty of ways to invert the equation and handle deadlines in an Agile way.

Deadlines aren't always wrong. As we all learned from Obi-Wan:

"Only the Sith deal in absolutes"

It's fair to say that in most cases deadlines are silly, unnecessary, and certainly not Agile, but it would take a fool to say that this is always the case. The architypal case is software needed for a time-sensitive use, such as election tracking software. If the software isn't ready in time for the election, it wouldn't make sensible nor practical to postpone the election, and it doesn't seem to be very customer oriented to just say 'Sorry, looks like we took too long. I know this software you're paying us for is completely worthless, but deadlines aren't Agile so how can you really hold it against us for not meeting them?'

It's not very Agile to tell your customers to shove it for wanting something that is time-sensitive, and at the end of the day somebody is going to have to build these things. So how can we still make the customers happy and still deliver seemingly reasonable solutions to things which are time sensitive? Well, if developing software takes an uncertain amount of time, and the deadline isn't variable, something else will just have to be variable to handle that uncertainty...

If the delivery date is held constant, some other aspect becomes a variable. As we all know, there can be a wide amount of uncertainty in software projects. Something has to be made variable in response to this uncertainty if you want success in your project, and usually that is the delivery date. It seems natural enough, anyways. But that isn't your only option. If you're stuck committing to a hard deadline, the way to handle that is to make your delivered features variable. Prioritize a list of features, communicate clearly that there is uncertainty in the amount of features that can be delivered by that date. Work with the customer to prioritize these features so that the most important ones will have a higher likelihood of being shipped. Then, it's business as usual, only when the deadline rolls around you ship whatever is ready to be shipped. In this model, shipping more features is the analog to shipping at an earlier date, and shipping fewer features is the analog of shipping at a later date.

Dogs
  • 1,166
  • 7
  • 11
12

Deadlines are traditionally based upon the business lifecycle. Tax software needs to be in by April 15th. Reporting for the next fiscal year might need to be done by July.

The Agile manifesto states:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

Deadlines are a contract. They are a plan. They do not respond to your team's velocity. They do not change if you lose your three best developers.

Deadlines are not Agile, but Agile can give us feedback on deadlines. Agile let's us know if our velocity will not let us make a deadline without a feature being cut. It also let's us know if we need to hire to make a deadline. And in some cases, it let's us know that a deadline is impossible, when there are no features left to cut.

The best thing an Agile team can do, is let their velocity and prioritized backlog drive the deadlines. This will give estimated delivery dates. If those fall outside the deadline, then its time for a serious talk with the client and determine if the deadline is even doable.

Stuart Rossiter
  • 103
  • 4
stevebot
  • 2,003
  • 2
  • 16
  • 19
  • 1
    Sometimes, you have to ship by a certain, non-negotiable date (a deadline). In that case, the best thing that an Agile team can do is let the deadline drive their backlog, giving the estimated feature-set at the deadline. If this estimated feature-set fails to meet the client's requirements, then it's time for a serious talk with the client and determine if the project is even doable. – Eric King Feb 24 '15 at 22:20
  • @EricKing yes, you are right, Agile can work with deadlines, I think I have been reading your statements as "deadlines are Agile" instead of "Agile works with Deadlines." – stevebot Feb 24 '15 at 22:25
  • Thanks for your comment. I think we've both been talking past each other for a while, and maybe it just takes a certain phrasing to make things click. I haven't been meaning to say "dealines are agile", but I can see how it would come across that way. Sorry about that. – Eric King Feb 24 '15 at 22:30
8

I would say that delivery each sprint is non-negotiable. You assess the work, you put card sizes on it, and you load up enough to keep your team busy until the sprint ends (and the sprint should be small -- anything from a week to a month). "Delivery deadlines" should be based on historical trend of completed work against anticipated work. Agile adds/removes nothing from the old "cost/time/scope" constraint idea, it simply uses scope as the preferred method of managing slippage on the basis that better prioritization against scope is generally preferable to spending more money or time.

Some people seem to confuse agile for "wild west". Agile doesn't mean anything goes. Agile means that we stop lying to ourselves about how well a reasonable person can estimate. Basically we can estimate software development about 2 - 4 weeks into the future. Beyond that, it's all varying degrees of swags and guesses. Worse yet, the cost of providing estimates for things further and further out into the future approaches the cost of just doing the work. For whatever reason, Project Managers have historically been unwilling to admit these absolute truths to customers. Agile simply adjusts that thinking by asserting that there is a limit to how well we can predict the future in software engineering, and makes a subtle switch to "evidence based estimation" for long term forecasting. By giving dead certain delivery in small chunks, and evidence based delivery for long term stuff, we get something close to the best of both worlds -- we get to be truthful about what we actually are capable of estimating, and we can provide fairly reasonable estimates of long term future delivery based on what we've been delivering so far.

Calphool
  • 1,727
  • 11
  • 9
7

TL;DR

Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development.

Many answers here are likely to focus on the engineering aspects of the question. Instead, I will address this from a project management perspective.

A deadline implies a great deal of up-front planning which is not in line with agile principles. Instead, iterative development models rely on time-boxes, cadence, and release cycles that include just-in-time planning, but not the "big, up-front planning" that is generally associated with traditional project management deadlines.

It is still possible to do release planning with agile methodologies, but the plans are generally based on an estimate of the number of iterations required to meet a goal rather than management targets set by fiat. That isn't to say that shipping dates can't be set, or that goals can't be met, but the way that they are defined and met is quite different than in traditional project management methodologies.

Think Time-Boxes, Not Deadlines

However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?

This is a common misunderstanding of the agile principles. Agile frameworks such as Scrum and Kanban are not focused on deadlines, but rather on time-boxing and a sustainable cadence of delivery.

In Scrum, for example, the Sprint is not a "deadline." It is a time-box which is filled with the amount of work the team estimates will fit within the time-box without overflowing it, and is then either "done" or "not done" when the time-box expires. Once gone, the time-box is gone forever; any work that is not done must be re-planned and re-estimated within a new, equally ephemeral time-box based on then-current (rather than historical) needs of the project.

The importance of the time-box is that it creates both a predictable cadence for stakeholders to review progress, and a sustainable pace for the team in which to deliver potentially-shippable increments of value. The work is incremental, and follows the cadence; the concept of a big, up-front deadline is therefore not in line with agile principles.

Release Planning Based on Time-Boxes

Perhaps the one area where people have the most difficulty mapping agile processes to traditional frameworks is in release planning. Release planning often involves either fixed-scope or fixed-date deliverables. In agile frameworks, release planning is usually done through an estimation process where scope is explicitly defined as a mutable variable, while release dates are estimated in iterations.

For example, a project may be committed to releasing v1.0 of a project at the end of 20 iterations; the scope of what is released may change over the life of the project (as scope, features, and priorities can change at the start of every Sprint), but the target dates for each release is fixed in the project plan. The team strives to deliver a potentially-shippable increment each Sprint, and the Definition of Done includes quality checks such as continuous integration to ensure that the project is in a releasable state at the end of each Sprint.

Occasionally, you will see agile projects where the scope is fixed, but because scope is the mutable variable in agile projects, the release date may change over time as the scope of each iteration adjusts, changes, or adapts to the evolving needs of the project. I certainly don't recommend the fixed-scope approach to agile teams, especially inexperienced teams, but there are times when it's the right approach.

See Also

CodeGnome
  • 1,270
  • 7
  • 13
  • ...sort of... but over time the team better be focusing on getting the mount of work to fit those "time boxes" well. If you just accept that your time boxes and work completed are unrelated, then you're doing cowboy coding, and it's completely unpredictable. I would say that perhaps it starts as "time boxes" and over time it becomes a somewhat non-negotiable deadline as the team gets better at predicting how much work they can handle in a sprint. It's about a team self-training to become excellent at short-term estimation, because that's where predictability comes from. – Calphool Mar 06 '15 at 16:18
4

Think of deadlines as commitment. The fact that the project is agile doesn't mean you shouldn't commit to deliver given features for a given date.

What agility brings is what happens in between. Instead of having a strict software requirements specification document which defines that you should deliver feature A composed of sub-features B, C, D and E for a given date, you commit to deliver the feature A for a given date, given that at the early stage, neither you nor your customer knows what the feature will look like, or would it have sub-features B, C, D and E or maybe B and C, or a dozen of other sub-features.

Imagine a company which previously delivered goods to small companies only and have just signed a contract with a large corporation. This large corporation uses EDIFACT, and it appears that the current accounting software used by your company doesn't handle EDIFACT. You're requested to create a plugin which does that, given that contractually, your company should be ready for April 15th.

The agility would mean that intermediary steps will be delivered progressively, and be based on regular feedback. Basically, you'll show your progress to the accountants, and they will tell you what they think about it, what are the possible issues, etc. This also means that maybe originally, accountants had a great idea which, they thought, could improve substantially the user experience. Three weeks later, it appeared that not only it doesn't improve it that much, but it will also result in one month of additional development. Thanks to Agile, you can then redirect your efforts from this feature to something else, making sure to deliver on time.

You should also understand the point of view of the customer:

  • Often, businesses need a specific delivery date. For instance, you can't deliver the Olympic games online streaming service after the end of Olympic games. Business-wise, this is simply a failure, with huge negative consequences.

  • Without having a commitment, it is tempting for a developer or a subcontractor to either be perfectionist or make the project low priority. While the regularity of the sprints help, it doesn't totally prevent this risk.

    I'm not fond of deadlines for that, especially since deadline slips happen very easily, but I still understand why many companies do that. It is not always easy to see that the project is behind the schedule by looking only at the sprints: a missed deadline, in this context, may be a clear reminder that something goes out of control and should be dealt with, right now.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • Thanks, but why is it that the regularity of sprints doesn't totally prevent this risk? Also, I like your example of the Olympic Games, but I think a requisite is that scope and cost and not bound. If I put one developer on that project and was required to deliver all features, the deadline would not really help and would most likely drive us to deliver a very low quality product. – stevebot Feb 23 '15 at 20:32
  • The regularity of sprints doesn't prevent the risk because it's relatively easy for a manager to trick the stakeholders to think that the project is going just fine. Things like “We didn't implement this thing because you've put an accent on those two things during our last meeting.” or “Two of our developers are on vacation, so we did only half of the job during this sprint.” are difficult to argue about for the stakeholders, and in every sprint details, they may lose the overall picture of the project. – Arseni Mourzenko Feb 23 '15 at 20:38
  • then you have a problem with transparency and putting a deadline on top will not help. Those excuses will just as easily be thrown at the deadline too and this is almost always what I see happen in real life. – stevebot Feb 23 '15 at 20:39
3

eXtreme Programming states about release planning:

The base philosophy of release planning is that a project may be quantified by four variables: scope, resources, time, and quality.

Which seems fair. It also states that

No one can control all 4 variables. When you change one you inadvertently cause another to change in response. Note that lowering quality to any less than excellent has unforeseen impact on the other 3 variables

And as already noted by br3w5, increasing resources is a bounded solution. You can probably add a couple people that were already part of the team if they were dispatched on something else. But you cannot simply increase the team size fast and indefinitely, at least not without team re-organization which takes lots of times.

So, with irreducible quality and fixed resources: a deadline being a time constraint, it means you need to adapt scope. And using agility gives you the mean to meet the deadline with the most productive scope possible. However, you can usually guaranty that some part of the scope will be done in time. This is the part that you can trustfully estimate its time to be bounded below the deadline. Typically something that is really close to what you have done several times and has little unknown.

Juh_
  • 171
  • 6
1

Deadlines are not agile, they are:

1)Waterfall, and 2)Wrong.

Software and deadlines do not work well together and never have. In many ways, the Agile methods are a reaction to the massive problem of missed deadlines or software which was abandoned when it became clear that the deadline could not be met (as well as budget issues, too).

Agile attempts to inject reality into the situation by saying "You know the deadline or the features are going to slip and/or change, we know it, so let's get off on the right foot and not even pretend".

The key is that the deadline becomes simply a release date for the first version of the software. That might still be written in stone - say, the software is for academic use and MUST be usable by the start of term - but what you will deliver is not. You have a minimum viable product that everyone is very sure can be delivered by then, and you have a load of "would like to haves". Instead of everyone throwing up their hands when it turns out that the entire list isn't going to be delivered by the "deadline", you make sure you get the MVP out the door and as many of the "would like to haves" as possible and then assess the cost/benefit of the remainder at that point.

Anyone who's played computer games for any length of time knows exactly how this works! If the first release is up to beta standards many gamers are happy, so low are the expectations of what "firm, real deadlines" mean in real life.

So deadlines are not agile, they are holdovers from the days when people thought that software could be treated like hardware and steel engineering. We've learnt that this is neither possible nor desirable, since it throws away the greatest advantage software has over hardware: it is soft.

Agile tries to exploit this softness by allowing goals to develop and change over the course of the project in a way that a bridge design never could.

Nagora
  • 159
  • 1
  • boy, they dislike your rant against monolithic deadlines more than mine. good job, N. – robert bristow-johnson Feb 24 '15 at 04:15
  • @robertbristow-johnson Apparently "they" have no experience with real-world development. A deadline being "a reality" never stopped a project being late or incomplete. Oh, well. – Nagora Feb 24 '15 at 07:37
  • 4
    I have no clue why people downvoted you. I've been doing agile/xp app dev for over 10 years in a Fortune 100 company -- introduced it here as a matter of fact, and I see absolutely nothing wrong with what you said. I upvoted you back to zero, because whoever downvoted you has to be an agile newb still clinging to their old reality for God knows what reason. People are too simplistic. They think that "Software and deadlines do not work well together" is an absolute. You aim to hit EVERY sprint deadline. You just don't lie about your ability to hit long range estimated dates. It's that simple. – Calphool Feb 24 '15 at 18:20
  • 7
    @Calphool I have issue with saying that deadlines are waterfall (they exist no matter what methodology is used - they even exist for cowboy coders) and wrong (they exist because of external constraints of time - no more wrong than "we have to have this code run on that hardware with some minimal performance"). It is a time constraint on what an acceptable solution is. Filing taxes by April 15th is a deadline. Having the software to the distributor by Nov 1 so that it can be on the shelves by Nov 27 is a deadline. Neither of these are wrong. –  Feb 24 '15 at 19:31
  • 4
    @MichaelT: If you haven't already, I'd suggest you read Tom & Mary Poppendiecks' book "Leading Lean Software Development: Results Are Not the Point". He's simply conveying a fairly popular meme in lean/agile circles. If you and your team are focusing on deadlines more than you're focusing on continuous improvement, you're not really living agile. You might be doing scrum, but not living agile. Do long term deadlines exist? Obviously. Are they what agile teams should focus on? Absolutely not. Deadlines are *incidental* to agile thinking. – Calphool Feb 24 '15 at 19:46
  • 4
    @MichaelT The OP referred to project deadlines and that's what I'm responding to - long term deadlines set by a PM at the start of a project rather than a sprint. *Certainly* there are deadlines of a sort in agile, but they have a very different nature to what people typically mean by project deadlines, but maybe it's just semantics that's the problem here. – Nagora Feb 24 '15 at 19:54
  • 1
    So, if deadlines are not agile, when can I expect my software to be ready by so that I can market it to my customers? – Ellesedil Feb 24 '15 at 20:30
  • 3
    @Ellesedil: Tell me your most important feature, or your minimum marketable feature set, give me a few weeks to a few months to build up a track record against your desired feature set (varies depending on how much you're asking for -- it takes more time to predict how long it'll take to get to the moon vs. Pittsburgh). Then I'll tell you, and since my estimate was built on *actual deliveries of useful software*, we'll be able to bank on the estimate, unlike the fairy tale you're forcing me to give you at the outset. – Calphool Feb 24 '15 at 21:22
  • 2
    @Ellesedil I would say that part of the problem is educating the business that software is not a closed system. The best we can give our estimates. Agile is transparent and works with this fact. Thus I can let my client know an estimated date, but I won't lie about it. – stevebot Feb 24 '15 at 21:24
  • 2
    @stevebot: Absolutely. People, until they are corrected, assume software development is like building buildings or roads. It's not. It's more like writing a story, or travelling to a distant city. Very little is set in stone, and very little is highly predictable. So, people ask for you to hit deadlines, but they don't know that any answer we give is at best an educated guess, and at worst complete nonsense. A better way to frame the situation is: "Tell me what's most important, and I'll focus on that so you're getting the most bang for your buck, and we'll figure out the story together." – Calphool Feb 24 '15 at 22:41
  • This answer seems to contradict itself. It first claims "Deadlines are not agile" but then "The key is that the deadline becomes simply a release date for the first version of the software." An agile project may be able to release some features _before_ the deadline, or even after just a few sprints. Perhaps a small rewrite to clarify and link back to the Agile literature may help. – dcorking Feb 25 '15 at 10:28
  • I'm sorry. If agile methodology isn't adaptable enough to provide a reasonable expectation for when a finished project will be available, then it might as well be a government project: at constant risk of being overt budget and indefinitely delayed. If you can't tell me how long it will take until months into the project, then how can you even estimate how much the project will cost? Do you expect your customers to just write blank checks? – Ellesedil Feb 25 '15 at 12:14
  • @Ellesedil: It's simply a minor variation on basic project management that's existed since the 1950s. Classical project management: you have three constraints on every project. 1) Time, 2) Cost, and 3) Scope. In order to get "extra juice" on one, you must give on the others. Agile says: "give on scope always, but MAKE SURE you're delivering the thing with the highest value, every sprint". Your most important features will be delivered by a date. You allocate funds to a team, they prove to you every 2 weeks that they're delivering your most important features, where's the problem? – Calphool Feb 25 '15 at 16:11
  • 1
    With what you just described @Calphool, nothing. I have a deadline (time), a budget (cost), a list of features that are **required** (scope, may be a large list), and a list of features that would be nice to have (extra scope, may be a small list). Then, what makes deadlines "not agile"? – Ellesedil Feb 25 '15 at 16:46
  • 1
    @Ellesedil - the issue here is "*project* deadlines". If you're starting off a project worth the name and saying "in X months time I must have everything on this list done and tested" then you're doing waterfall and will probably fail. Planning everything up front to the degree needed to do that has been tried and it has repeatedly failed. Agile is an attempt to deliver not only what you think you want, but what you realise you can/need to have as the project progresses and the environment changes. Project-length deadlines with written-in-stone goals is what I'm saying is not agile. – Nagora Feb 25 '15 at 16:59
  • @Ellesedil Billing is the hardest part of Agile, but only because buyers are stuck in a mode of thought that NEVER worked. Projects went over budget and came in late when costs and time requirements were presented up-front. But you're asking for exactly that and complaining that Agile can't give you it. Well, neither could waterfall, it just pretended it could. You're asking for the *exact* thing that makes waterfall projects fail. We're saying "don't do that, and don't kid yourself that you can or ever could". – Nagora Feb 25 '15 at 17:02
  • 1
    @Nagora: With that philosophy, how would you ever present a bid to a potential customer? Customer: "Hey, how long and how much would it cost to have a website to play cat videos?" SW Company: "We're agile, we have no idea." Customer: "Good talk, we'll be in touch after we never consider your proposal." – Ellesedil Feb 25 '15 at 17:12
  • 1
    @Ellesedil Well, for a start, most clients have been there and bought the Waterfail t-shirt so they already know there's a problem. Secondly, you work with them to prioritize what they want and get away from the "all or nothing" thinking. Then you make a bet with them: "we'll start doing these things in priority order in deliverable steps of 1 month and charge you for delivered value. At any point you can say "screw you" and move on. We bet that you will keep going because you will see *actual* value faster and have more chances to refine the product than you ever have before, for less risk." – Nagora Feb 25 '15 at 17:51
  • @Ellesedil: I'm not sure if you're being pedantic, trolling, or if you're legitimately confused. People have been doing time/materials contracts since time immemorial, so there's nothing new here. When a customer goes to a contractor and says "I need ALL this functionality by THIS date", what you get is a bid (lie) that's big enough to cover the fact that nobody has any real idea what it'll cost. Software is *not* like building a house. Forcing it to be that way simply makes it cost more. – Calphool Feb 25 '15 at 18:42
  • 1
    Oh, I'm definitely confused, because different people appear to be saying different things. So, here's a scenario: I'm a company that does stuff and I need a software solution that handles a specific aspect of the stuff I want to do. I'm going to talk to a few different companies in a bidding process, at which point I'll negotiate and sign a contract for that work. If deadlines are not agile, and it's even impossible to estimate a time frame or cost, then how can your sales team convince my team to write a large check made out to your company? – Ellesedil Feb 25 '15 at 18:57
  • 2
    @Ellesedil By telling them that they don't need to write a big cheque. You'll write a *small* cheque and after a month decide if we're a bunch of losers like the guys you wrote the last BIG cheque to and if so, tell us not to expect any more. – Nagora Feb 25 '15 at 22:26
  • @Calphool "Software is not like building a house". Unless you are doing S&R then, it's exactly like building a house. In my business, we deal with construction and software and it's the same (conserving the scales). – magallanes May 18 '18 at 03:56
  • @magallanes Care to elaborate? In what *ways* are construction and "s&r" like construction? Software development in general is about taking ideas you expect to create value, implementing them, measuring results, and pivoting. This doesn't have a lot to do with construction. Once a building is built, the costs of pivoting are generally prohibitive because buildings are subject to physics. Software is not. – Calphool May 19 '18 at 19:06
0

The purpose of software development methods, when understood correctly, is to make us more productive by focusing our thoughts, and to provide a common language for typical situations. It's about inspiration and enabling, not about mind control and guilt.

Following a software development method literally with no compromises whatsoever corresponds to what is called radicalism or fundamentalism in other contexts. The pure form of this aberration is rarely seen in practice because it typically leads to rapid failure in the market. But of course when developers compete in the hard task of implementing a specific method, overshooting the mark is a natural occurrence.

The problem is exacerbated by the fact that missionaries and evangelists primarily target those who still need convincing to use the method at all; and even if they do preach moderation, human nature ensures that it gets less attention.

0

Answer "probably no"

The Project_management_triangle states that cost, time and scope (and also quality) depend on each other. ("pick two and get the 3rd")

A scrum sprint chooses fixed time (i.e. 7 days=length of sprint) and cost (i.e. budget for 7 team members) and estimates the scope (the number of stories to be done in sprint)

If management or sales-department tries to define all three (cost, time and scope) then it is not agile in the sense of scrum because the team cannot cannot promise to reach the goal (without violating quality=definition-of-done)

Professional management tries to define cost and time and reduce scope if necessary if there is some fixed date to be met.

k3b
  • 7,488
  • 1
  • 18
  • 31
0

Can this not be answered simply and directly?

No deadlines are not agile.

The whole point is to build what you can in an iterative fashion learning and adapting as you go.

A deadline is "you have to deliver x by y" which fails on both counts in that you're promising a fixed deliverable in a pre-determined timescale (where agile says we're not sure what we're trying to deliver, and the learning from agile teaches us that even if we do know its very difficult to have certainty about timescales - or its a solved problem and we shouldn't be doing it anyway).

Having established that the answer to the question is "No, deadlines are not agile" - then we are able to have an interesting conversation that addresses the question of "how do we address deadlines in an agile context" and there is a lot of good thinking about that in the other answers.

To my mind a reasonable answer to the latter is that we will deliver increments of value early and often and we will see where we are in due course - but there is no one size fits all.

Murph
  • 7,813
  • 1
  • 28
  • 41
-3

The degree of agility required in one's work is inversely proportional to how high their position is on the organization chart.

"Agile" is good, for what it is. "Agile" sorta means "open-minded coupled with sufficient competence." It's the grunts at the bottom that have to be the most agile.

If, at management levels, the pointy-haired boss was agile enough to understand that pushing a deadline back a week will make for a better product, or will make for cleaner, more bug-free, and more leverageable code so that the company (or the division) saves two weeks in the future, that's an agile deadline.

But like enlightened self-interest, it doesn't really exist.

robert bristow-johnson
  • 1,190
  • 1
  • 8
  • 17
  • 5
    A deadline that can be moved isn't a deadline. That's called a calendar date. Deadlines are things like Black Friday - either it's in store or it isn't. Still, Agile means I have the best I can have by that deadline. – MSalters Feb 24 '15 at 00:19
  • so, if it misses that deadline, but it's in the store the following week, does the manufacturer always die? missing that deadline incurs cost. but what if that cost is more than made up for with a better product, that impresses customers more with their first impression (*"you never get a second chance to make a first impression"*) and has other benefits that exceeds that cost? if management is smart enough to make a tactical decision to defer release (it's bumping the deadline, not ditching it) to the benefit of customers and manufacturer alike, ain't that "agile"? – robert bristow-johnson Feb 24 '15 at 04:14
  • Have you ever had Black Friday deadlines with Walmart? The feeling I got was that if you screwed up this year, you won't get a second chance next year. That's literally "no second chance". – MSalters Feb 24 '15 at 07:59
  • 3
    listen i code in the audio and music instrument area. certainly the product has to get out the door in order to make money with it. but deadlines have literally caused some ill-developed crap to go out the door that the customers, company, and future developers were forced to live with for years after. – robert bristow-johnson Feb 24 '15 at 15:14
  • 5
    The thing with Black Friday sales is that it's a marketing attempt to create a false scarcity of time and product in order to get people to behave irrationally and buy things that they otherwise wouldn't. This example of induced irrational behavior doesn't seem to be all that different to some approaches to software project management. In arguing that creating false scarcities of time with software is not a good idea, I'm not saying that real scarcities of time are impossible because they obviously are in *some* contexts (and are crucial at that). – shuttle87 Feb 24 '15 at 17:56
  • "The degree of agility required in one's work is inversely proportional to how high their position is on the organization chart." Tell that to the owner of a startup. – Calphool Mar 06 '15 at 16:23
  • @Calphool depends on how agile the startup is. – robert bristow-johnson Mar 06 '15 at 18:03
  • Any startup that survives beyond a year or so is highly agile. Ever worked at one? – Calphool Mar 10 '15 at 16:04
  • multiple times. and what you assert is decidedly false. **many** startups that survive a decade become quite satisfied with their M.O. and calcified. – robert bristow-johnson Mar 10 '15 at 16:20
  • @robertbristow-johnson at that point they are no longer startups and so the assertion does not apply to them. – user253751 May 23 '18 at 00:33
  • so @immibis, how would i modify the assertion to be accurate and applicable. how 'bout: \\" **many** companies that survive a decade become quite satisfied with their M.O and calcified, ....."// – robert bristow-johnson May 23 '18 at 00:44
  • @robertbristow-johnson Did you read my comment? All startups that survive a year ("or so") are agile. But the ones that have been around for a decade aren't. But those ones aren't startups, so it doesn't invalidate that startups are agile. – user253751 May 23 '18 at 01:33
  • @immibis, i'm fine with defining companies that have been around a decade a non-startup. i'm fine with changing what i originally said to *"many companies that survive a decade become quite satisfied with their M.O. and become calcified,.."*. or how 'bout: *"many companies that once were a startup and survived a decade become quite satisfied with their M.O. and become calcified,.."* – robert bristow-johnson May 23 '18 at 03:45
  • but i am not so sure that i agree that every single startup that lasts a year is doing [Agile software development](https://en.wikipedia.org/wiki/Agile_software_development). if you mean *"agile"* in a more general sense, maybe that's more accurate, but i am sure there are startups with lotsa angel moneybags behind them that don't get agile but survive a year just because of the initial investment. – robert bristow-johnson May 23 '18 at 03:49