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.

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.

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.

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.

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.

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.

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.

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

• How to Perform Agile Release Planning

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 15^th.

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.

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.

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.

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.

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.

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.

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.