Stop Getting Stuff Done After You Said You Couldn’t

We have all been there. We are in a meeting being told we must complete all these features by a certain date. We keep telling them it is not possible. There is simply too much work to get done by that date. But somehow, when that date arrives, all the features are done!

What happened? How could you get something done that you claimed was impossible? If I am the person that made what was first described as an unrealistic demand, but all the features were completed on time, I think I can ask for more. Clearly the dev team was wrong; they could get it all done. And I realize I am an incredible motivator!

If you are a dev, you are thinking, “I had to work nights and weekends and cut out unit tests to make that date.” But I bet many of you have never said that to the person making the demands. Others have said that but know that they just do not listen. But again, I ask, “How did it get done? Who paid the consequences?” You did! They are home with their families while you are burning the midnight oil. They do not see you there at night or on the weekends because they are home with their families. I am not saying they are evil people. Because they are not there at night or the weekend so they do not know that you are.

I see several problems with this all-too-familiar situation. The first problem is most conversations begin with a date. That is the first mistake. When you lead with a date then ask if can we make it, developers start to subtract back from that date in their heads and start making compromises. The first time-saver is to cut out testing, which will lead to customer satisfaction issues and technical debt. Technical debt, like credit card debt, accrues interest that you must pay eventually. The hit to your reputation with your customers will take even longer to repair.

I have had to sit down with my product owners in the past and demand that they do not mention any dates in our planning meetings. I knew if dates were mentioned we would never get a true measure of the time the team needed to complete the task. The team would find a way to get it to fit even if the work required more time. What I needed was the teams honest, unbiased opinion of the effort of each task. Once that was established, the onus was on the product owner to set the priority of the items such that they got what they needed by the date only known to them. Dates became forbidden. The simple fact was if you need 9 days’ worth of work in 5 days, you were not getting it.

This also forced my product owners to compromise on what the team delivered. When they are working with real numbers, it becomes clear that they simply do not have enough time. The estimates became the cost of the item and the product owner only had so many hours of currency to spend. An additional benefit was making my product owners take a hard look at their priorities. Once they realize they cannot have it all, they quickly adjust the backlog to ensure they get what they need.

Quality Date FeaturesWe have all seen quality suffer to make a date. If anything should be nonnegotiable, it should be quality. This reminds me of the diagram where you can pick two between good, fast, or cheap. I have a similar idea. The options are date, features, or quality, but you can only pick one between date and features because quality is nonnegotiable. You can move the date or you can reduce the feature set. Without a date as a target, you can estimate to our agreed Definition of Done and not cut corners to make dates.

I know dates exist, but many are not as important as we are first led to believe. They are used to motivate but do more damage than good. How many times have you been told the date cannot be moved, but when you fail to deliver, the date moves?

When you do have an unmovable date, one that could cost the company due to fines for missing regulations, I still recommend that you do not share the date. What you must do is prioritize the items that satisfy the regulations ahead of items that do not. Stop being greedy. This will bite you in the ass. Eventually developers will be exhausted from the constant fire drills and death marches. I have news for you. The first developers to leave are the best ones you have because they have options.

So how do you fix this? Donovan cannot be suggesting we fail on purpose. The easy answer is hire “the asshole.” What I mean by that is it is very hard to say no to your boss. I struggle with it myself. But it is easy for me to say no to your boss. When I was a process consultant, I felt that was my job to come in and protect the teams from these unrealistic requests and say no to people that might have never heard it before. To share the numbers on why what they are requesting is not possible. Then help them truly prioritize their backlog. So many product owners do not think they can ship until you complete each item on the backlog, so why does the order matter? When you are done, we will ship and I need it all. But that is not how agile works. You do not have to reach the bottom of your backlog before you ship. You can ship as soon as you see value.

One other trick I have used to have the product owner focus on the true priority of the product backlog is to have them set the priority as if this is the last sprint we get to work for them. After this sprint, we are going to work on another project. So, given you only have one sprint left, what must be completed? I learned this trick because at one company, that was the case. The team would move very quickly from project to project porting from one platform to another. Once the product owner realized they do not get the team forever, they got their product backlogs in order. It forced them to really justify if they needed every bell and whistle they were asking for. It is a very powerful motivator for them to engage in this process.

Once the product owner steps up and truly takes ownership of the backlog and works with real data, the entire team will thrive. Developers now get the spend time with their families and deliver higher quality code they can be proud of and your customers are excited to use. Take back your time with your loved ones.

Comments (2) -

  • "Dates became forbidden." I Strongly disagree with this. Time is the ONE resource nobody has yet figured out how to change...except maybe Elon Musk? Dates and an awareness that time is a FIXED resource is CRITICAL.

    I encourage Teams to be VERY, VERY realistic with accounting for their focused and productive time.

    Many of the highest performing teams I've been on...have had a daily cap of 2.5 hours of productive work per day....and that's at the high end (I've seen teams that have 1 hour too). Think about that for a moment...1 hour a day.

    Take out meetings, take out water breaks, take out process reviews, take out standups, take out learning time (which is a MUST), take out the buffer (for critical break\bug fix) get down to 2.5 hours a day per team member of "productive work".

    That means in a 2-week sprint you only get 25 hours to budget for the highest value work.

    And I hear the manager exclaim "but I'm paying for 80 hours of a developer's time...and only getting 1/4 of that time. They must be soooo lazy".  Yep "lazy" developers....come to that cold hard realization and the faster you do the better your company will be at retaining talent and being able to deliver value.

    Come to the realization that the BEST developers in the world are the laziest developers.

    The team can and should track focus factor. How focused is the team (what takes the team out of focus)?

    Now for teams that are trying to get MORE stuff done...they have to come to the realization they have to actually DO LESS (as a PO I can say and don't say it hurts to have to do LESS...but Slow is Smooth, Smooth is Fast) and the team has to work to have faster OODA loops.

    I strongly suggest teams that are struggling look at having better metrics and digging into trends over say 6-8 sprints (3-5 months)...change is slow and takes TIME.

    Also I strongly encourage teams and individual engineers to DESIGN a feature’s functionality with time in mind from the very onset. Examine the target audience and use case, and develop a timeline for implementation. In modern agile teams at the end of each sprint there MUST be a deployment to Production (or as you say "delivery of value to our end users.").

    Teams should initially deploy the feature as ‘off’ in production and then implement the DESIGNED release and rollout strategy.  This could be an incremental percentage rollout, individual user targeting, or targeting groups of users.

    Teams that today are not delivering software in fast, automated, CONTROLLED, and MEASURED ways should look to move to feature flags\toggles\attributes systems.  Two great examples: and

    Time is real.

    Developers MUST get to spend time with their families and they MUST get distraction-free time to deliver high-quality code.
  • I see your concern and think I was not clear. Dates were not allowed in our planning meetings. Of  course they exist but I don't want them biasing my developers estimates. If I know when it is due I will try to make it fit any way I can even when it does not.
    And if you have every written software you have seen dates slip. So they are not as immovable as they are first presented to us.
    As I said in the post the onus is on the product owner to set the priority of the items to get what they need when. They might be focused on a date but I don't want that date to influence my teams estimates.

Add comment