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.
We have all seen quality suffer to make a date. If anything should be non-negotiable, 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 the quality is non-negotiable. 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 to 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 the 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 to 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.