Show all posts
8 years ago

Do You Really Need a Deadline?

The concept of deadline has always been one of the sacred cows for any human activity.  Normally, with very few exceptions, what do people do with any project? They set a deadline and think that they will care about meeting this deadline somehow. You can see lots of examples for that in construction industry. Remember, China and the 2008 Olympics. They had a deadline for building Bird's Nest arena in quite a short period of time. In this case, it was really necessary to meet the deadline since the Olympics was to start on August 8, 2008.

How about software development projects? Product development? With agile methodology?

I think there are 2 options here: agile team does have external pressure for deadline, and the team is free to choose when to release. The main criteria for release is quality as observed in this tweet.

When reading blog posts and articles on lean and kanban (this one for example), I noticed that people are very wary of calling things their names and avoid saying it out loud - DEADLINES ARE CRAP. What matters is the work flow, the quality, the limits of WIP and the Definition of Done. So, if a team has no external pressure, the recommendation is to avoid extra stress by imposing unnecessary deadlines.

There's no rush for perfection, as they say. But how about external pressure? How about clients who bluntly say — I want this job done yesterday? Frankly, as I worked in outsourcing, I always felt an urge to say to such clients — if you want to have this done yesterday, you should have moved your a** yesterday and select a vendor who you trust yesterday. With custom on-demand projects, clients often fail to understand that meeting a deadline and completing a project on time is the responsibility of both customer and vendor, with customer even more responsible.

So, if you're with an agile software shop and you have such clients, there are 3 options:

  1. educate your clients on deadline concept as above and say bye to them
  2. bend over backwards, have stress, and deliver something-not-sure-what on a client's "yesterday" deadline
  3. patiently explain the client that only a part of what they want can be done by their deadline and prioritize work.

The sad thing is that the majority of clients will go elsewhere hoping to "get the job done yesterday". But if you really are competent, do good work, your reputation will start building up and at the end of it all you'll get a bunch of devout customers - especially if you work in a local community.

  • Michael Dubakov

    I think customers with “deadline is yesterday” mentality will not take agile approach. They will stick with waterfall and will seek for exact release date promise.

  • Benjamin Mitchell

    There’s an extra part to your point 3, which is to make the current work and future queued work more visible so that the client can see what is being worked on, what’s waiting and how quickly work generally moves.

    This is one of the benefits from using a Kanban board (or even more simply, showing queues to the business sponsors).

    Making things visible in this way helps keep the discussion more rational. As Michael Dubakov comments, managers would really prefer the Command and Control / Waterfall approach where the deadlines are promises and everything finishes on time (if only the world were like this …). It takes a long time to help them see how the world actually is and to accept there are limits to how much can be done and how long it will take.

  • Michael Dubakov

    Yeah, I think Kanban with Lead Time / Cycle Time metrics may be a really good start. If these metrics are reliable, managers will fee the control. Still it is required to convince them to try Kanban on practice 😉

  • Wille

    I think deadlines become an issue because people are poor at managing scope – rather than aggressively manage scope while at the same time not accepting stories/features that are not production quality, organizations make up arbitrary deadlines that will have an arbitrarily large set of features in.

    What would be more desirable in my opinion is better scope management and better engineering discipline to make sure code is always production quality. That way deadlines loose their meaning, as a production deployment can be made almost at any time, with any set of completed features.

  • Michael Dubakov

    @Wille I agree with you. If you can release after each feature done there is no need in a deadline. But often managers use deadline as an external pressure on the team. And I think in some cases it may be ok. But if the team has self-respect and responsibility, deadline is not required.

  • Jon

    All market driven businesses have pressure from the outside. Should, at least. I would never buy something without knowing anything about deadline. Would you buy a car without knowing when you’ll get it?

  • Marcin Niebudek

    I think having deadline is not so evil. In fact I’ve seen a project where deadlines were helpful and their lack caused… product owners to lose their focus.

    The problem is not in a deadline but in the scope that is being pushed into the time box created by deadline. But if you set a deadline and ask a proper question like “Ok, what can fit into our release by that time?” instead of “Here is the date, fit all in, go… go… go!” then the “deadline” will help you prioritize.

    For me this is especially true when you are at the beginning of a project or you are a startup company. At the beginning you want to move the mountains and almost all your backlog items are must haves. Without setting yourself some deadline you may loose (as a product owner) a focus on what is really important for your product and business. Am I being a devils advocate? 😉

  • Michael Dubakov

    @Marcin Niebudek Not exactly. When you start, it is required to define a MINIMAL set of features that should be in the product. It may be hard, but when you define this set, deadline is not required at all.

    So you are right about scope, but it has little in common with a deadline.

  • Michael Dubakov

    Cars and Software are quite different things. Car is assembled, while software development is a craftsmanship. If you want a unique car (designed specially for you with unique features), you will wait for years. Car maker will say you something like “Oh, it’s gonna be expensive. And it’ll take 2-3 years to produce. But if you agree to remove adaptive cruise control and advanced braking system, maybe 2 years will be enough to build this car”.

    Assembly line production is a different thing. You can’t compare apples to oranges.

  • Wayne Simacek

    I think deadline is at an extreme spectrum of customer expectation and communication channels. When I walk into a restaurant, the first thing I want to know is how long the wait is. I will then factor that in with how hungry I am, the quality of their food, and my other expectations for a nice dining experience.

    With that in mind, if you walk in and all you see is this full waiting area and a mad flurry of activity and the host responds “we’ll get to you as soon as we can, but our food is worth the wait” what do you do? I might take a chance until either my hunger threshold or my patience is exceeded. After that, I might not come back.

  • Martin Proulx

    I feel you are confusing the need for deadlines (time box) with the inability to properly plan.

    IMO, time boxes are a critical part of Scrum and force the team to properly plan and execute their work in order to meet their commitment.

    Ability to plan is something that can be learned and should be learned. Transferring your inability to someone else is a different issue and than the situation becomes the following: will you accept someone else’s problem for compensation?

  • Olga Kouzina

    @Wayne Simacek If you go to the restaurant, that’s restaurant – it’s not a product development (project work, custom software development, whatever). The time to get you the food matters a lot, restaurants know that, and they do their best to stand up to their promise. Otherwise, they’d lose their clients – and in this case clients are more likely to go elsewhere and get what they want within the timeframe they want 🙂 Besides, a one-time meal is not that much important as the software that will be used by many people. Imho, the comparison with restaurant is not very correct here.

  • Casey

    I NEED deadlines to work. If I don’t have them, I don’t get anything done. The worst thing possible for me is to be given time.

  • Mikhail

    I agree with Martin. Deadlines help you focus your attention on things that need to be done first and downsize scope so deadline can be met.

    If your clients are in highly competitive market they do expect you to deliver and fast. In such market missed deadline may cost your client more than the total cost of the software project.

    So I don’t really need deadlines, but I do have them and I do need to meet them.

  • swag

    You’re kidding yourself if you think that sprint lengths aren’t a form of a deadline.

  • Michael Dubakov

    @swag Interesting observation 🙂 But if dev. team missed first sprint it is OK, since dev. team does not know its velocity. If it missed second sprint it is OK as well. However, if dev. teams missing sprints often, it is a subject to investigation.

    Basically, sprint is a deadline, but the difference is that it is realistic deadline based on known velocity.

  • Olga Kouzina

    @Mikhail Regarding “clients that expect to deliver and fast”: I can’t say any better than Kevin Schlabach did in the discussion thread of this topic in LinkedIn

  • Olga Kouzina

    @Casey As Justine Decker puts it in this discussion: “it is generally human nature and especially in social or work groups to push critical work off in the absence of a time-boxing element”.

  • Steve Petro

    I agree with Michael D…Sprints are deadlines based on known velocity. If velocity is known then deadlines become the time by which something must be finished or submitted….I would add that deadlines are created by the team, customer and or vendor. It is in the transparency of the delivery, process, business expectations and management of the project that creates unrealistic deadlines. If you have a customer who needs the team to deliver fast then the utmost transparency is needed. A business customer needs things yesterday, needs to own the process and be held responsible for the outcome….meaning prioritizing what features/stories are the highest priority/business critical; make scope and cost decisions based on their need and the deadline they need them by; understand the gaps,issues,decisions and dependencies that may cause for reprioritization; and understand the agile process. If a business customer is well informed and has transparency into the needed outcome a deadline becomes a milestone.

  • Bruno Guicardi

    If we are talking about deadlines imposed by business areas, customers etc. I would say we do not need it. In my experience, business areas push deadlines on IT seldom because they “need” something by that specific date, rather they do it because sometimes it is the only way to get “something” done from IT. Unfortunately they have learned that by previous experiences with IT, where the lack of delivery and continuous projects delays rule.

    Once business areas start experiencing continuous “delivery”, unrealistic deadlines set by somebody in a higher floor go down to abyssal levels.

  • Alexander Hrach

    I LOVE working in the flow, with quality as the one and only decisive matter.
    Kanban and lean concepts are WONDERFUL to work with, and I promote that in all of my consultig projects.
    But speaking in terms of project management (ipma influenced): If you don’t have a date of delivery AND a specified quality for your deliverables, you don’t even have a project, full stop.

  • Beth Plamondon

    Alexander – Thank You! If software development were happening in a bubble, all this would be more relevant. Deadlines are necessary to coordinate with all the other pieces it takes to make it work. If there are no deadlines – at least as a goal for delivery – then timing the delivery of servers, the marketing launch campaign, user or sales training, etc. (and the list is long) is nearly impossible. No business would ever allow Development to just keep working until their backlog is exhausted, and then start doing all these other tasks to utilize what’s been created.
    Agile methodology doesn’t talk about eliminating deadlines, it talks about aligning what’s delivered (features/functions) with the deadline.

  • Jacob Karma

    Deadlines are mostly damaging. To the product, and to the team members. But the client/stakeholders just can’t get enough of them.

    Great post.

  • Benjamin Mitchell

    There&#39s an extra part to your point 3, which is to make the current work and future queued work more visible so that the client can see what is being worked on, what&#39s waiting and how quickly work generally moves.

    This is one of the benefits from using a Kanban board (or even more simply, showing queues to the business sponsors).

    Making things visible in this way helps keep the discussion more rational. As Michael Dubakov comments, managers would really prefer the Command and Control / Waterfall approach where the deadlines are promises and everything finishes on time (if only the world were like this …). It takes a long time to help them see how the world actually is and to accept there are limits to how much can be done and how long it will take.

  • fertility drugs for women

    and I&#39m doing a trade deadline chosen not a lot going on Dustin Penner was obviously the big deal but did anybody see the Bruins had done their work in the week or two before. The Kevin DuPont of the Boston Globe joins us now — Gentlemen how are you …

  • Midix

    Sorry, I’m so late to comment on this. Just wanted to share my idea: when doing scrum, I’d call sprints not deadlines but checkpoints. Yes, you have to deliver something for each sprint, but there will be no rush and no penalty. In scrum, failure to deliver all the planned features just means that team velocity is not yet stable enough (but it will stabilize after some sprints), so initital estimates were wrong. If you explain to your client that for the first sprint the estimates for the work done are rough and that the client should clearly state his priorities, then everything should be just fine. So sprint is more a checkpoint than a deadline.

  • Ken Van Gilbergen

    I am following your reasoning, but sometimes deadlines are not in your hands. Let me give you an example. Some services your production code works on are going to be replaced (think google, azure, …) and there is a strict date to update your stuff. Another example would be deadlines enforced by legal requirements. (think cookie banner in EU) …

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy