I tend to think they do as long as the scope is variable and not fixed where the idea is to deliver value based on the time you have. Am I correct in my assumption?
I think of a deadline as a date for which, if you miss it, an opportunity (or a person, or a project, or an organization) dies.
For instance, we once had to get a newspaper site's galleries ready in time for the Oscars. Failure to do so would have meant we missed our opportunity to put up pictures of the stars in their beautiful clothes. The Oscars wasn't moving for us! Similar deadlines I've encountered are Christmas, summer sales, and the end of the academic year / exam marking deadlines.
In these situations, scope needs to be flexible; whatever is ready in time gets shipped.
However, a lot of companies seem to also have something I call sadlines. These have often been created around estimated scope, with or without development team involvement. Nothing and nobody will die, but if you miss them, someone will be sad. Their reputation is at stake, or dependencies within the organization have been managed around them.
Bizarrely, people tend to behave very pragmatically around deadlines in a way that they don't around sadlines. The appearance of meeting a sadline is often more important to sponsors and stakeholders than actually shipping something valuable or high-quality.
At that point you'll find you have fixed scope and fixed deadlines, no matter what kind of methodology the team says it's using.
This is a common pattern I see in projects where Agile's been adopted at a team level, but the organization itself is still transforming, and it's not yet safe for middle managers to say "no" to requests or to adapt their plans based on new information.
Note that this is an anti-pattern. It shouldn't happen on Agile projects, which have plenty of ways of dealing with it... but it often does.
Scaling and transformation methods are intended to help solve this, amongst other issues. It's usually outside of the influence of an individual project manager's ability to effect change, though telling the stories and providing evidence to those who can make change happen can help.
Do deadlines exist in agile projects?
Yes and no. A lot depends on your framework, and on your team's accepted definition of deadline.
What is a Deadline?
Historically, the term "deadline" was literally a line beyond which prisoners would be shot. In business, a deadline is both an expected delivery date and the point at which Bad Things™ are expected to happen if that delivery date hasn't been met.
Hard deadlines (as opposed to arbitrary targets) often result in lost business, lost revenue, lost jobs, or other unhappy results. However, a generic deadline is any time or date by which something is supposed to be completed. The problem is really when a process doesn't differentiate between the two uses of the term.
Deadlines as Delivery Targets
Scrum uses time boxing, and you could certainly consider the end of each Sprint a deadline by which something ought to be done. Dependencies within a Sprint and between tasks also generate deadlines. While a team may miss its forecast or fail to meet a Sprint Goal, this should be considered more of a learning experience and an opportunity for process improvement than a traditional Bad Thing™.
Other agile frameworks such as Kanban aren't driven by time boxes. An incomplete task in Kanban is either waiting, running, or paused; while people certainly have expectations about how long a typical job may take, this is usually a schedule forecast based on past performance rather than using the targeted delivery dates often referred to as "deadlines."
The general agile practice of decomposing stories into tasks of 1/2 to 2 days in length can also create deadlines, but this is more of a guideline than a hard requirement of any particular framework. I'd call that completion target more of an expectation than a hard deadline, but others might argue with that.
There's a reason practitioners of frameworks like Scrum use terms like time box, iteration, and forecast rather than loaded (and often overloaded) terms like deadline. While the word deadline isn't wrong, it often carries a connotation of "or else" that isn't really aligned with agile principles.
If you find yourself using the term deadline in an agile context to identify expectations or consequences for the project, you may want to take a closer look at how you're communicating about the process. From a purely definitional point of view, though, some agile frameworks like Scrum do have firm deadlines (primarily at iteration boundaries), while others like Kanban do not.
Sure. Deadlines are simply one type of finish line. With agile software development there are many possible finish lines: scope, time, money, value, etc.
Todd Jacobs wrote an excellent answer, but I feel he missed an important type of Agile project where deadlines definitely exist. The ones where there is a deadline, but the scope is variable.
This is common on research projects that are being drip funded. For example, I joined a team at the beginning of November. We had exactly two months to accomplish as much as we could. At the end of that time, our progress was evaluated. If it looked like the project would be feasible, we would be extended for another few months. If the team, and the check writers, felt it was worth while to continue, we would.
We were extended another 3 months and will repeat the evaluation at the end of March.
Basically, the idea is to set a fixed budget and accomplish as much as possible with that budget. When the budget is gone, the project is done. (Unless someone decides it’s worthwhile to allocate more budget.)
No, not necessarily. The scope is fixed for almost all of the software development projects. Only in certain cases it might change due to regulatory requirements. Otherwise it is fixed.
Please note, not capturing the relevant user story during the session (thinking it can be done later) is a different issue altogether.
For the industrial and research and development related projects, the scope can be variable.
Irrespective, the schedule deadline is either 30 days or two weeks known as Sprint cycle. This means, decomposing into units and working towards the deadline is the key.