Delivery Deadlines

“You can pick the scope of the work, or the delivery date, not both.”

There are some cliches in the software world, and we need to embrace their truth, not dismiss them because they are cliches. When it comes to delivery deadlines, that cliche is a hard truth.

I have yet to meet a tech leadership who does not understand that the unknowns in our work mean we cannot be 100% accurate in our estimates. The entire “Agile” movement is all about this. Yet your product leaders still often want both defined scope and accurate dates. They still ask for just one more change to the work, without changing the dates. 

As individual software developers, we need to push back against this. Because we cannot change the truth of “scope vs. date”, so the only result that can be expected when we allow our leaders to try to change it is to take more work upon ourselves, which often means overtime, which degrades the quality of our work overall. 

That is also exactly how you push back against such an event. Remind your boss that something has to give – if it is not scope or time, then it is quality. And possibly morale and team job satisfaction. There are occasions where the business needs will drive you to work more and reduce quality and morale. But be sure your boss knows it, and hears about it. That choice needs to be put on them, and they need to be accountable for the results. If you do not hold steady on this point, the accountability will flow downhill to you, and you will be blamed for the negative repercussions of someone else’s decision.

That is unfair to you. It hearkens back to the discussion of keeping score when negotiating your work environment – they are degrading your experience, and will likely punish you for it to add insult to injury. 

In addition to pushing back, you can also work on improving your team’s working processes to help your boss have a better sense of when a fair expectation of product delivery will be. The Agile movement has the right idea in this arena, although the formal methodologies that have arisen over the last decade or so have lost sight of their own purpose.

But you can break your processes down and restore them to their original purpose – to be able to have reasonable predictions of what work the team will deliver, and when. I recommend looking at everything you do, and asking whether it truly helps drive the team to that purpose. Do you have daily meetings? Do they help predict work, or are they just status updates? Do you have a tracking system for the work? Does it enhance your meetings and communication, or is redundant to other conversations? Which one could be removed? Do you “storry point” your work before starting? Does it help, or have you settled into a rhythm where your PO always sets up cards of 2-3 points, so you could just as easily skip pointing and just count cards?

It is outside the scope of this writing to deconstruct and rebuild every team process that is out in the wild. My main point is to spend a week or so spending effort to see what your process is, and to attack your own process — questioning whether any specific thing you do as a team either helps complete the work, or helps predict the work. And anything that does not do one of those two things is not needed.

Once you have streamlined your processes, you should have a reasonable amount of clarity towards what you do, and a reasonable amount of clarity towards how much work the team can get done each week/month/quarter. Use this to help your leadership understand your work capacity, and be firm that the responsibility to to make adjustments and decisions if the amount you can deliver does not match their desired speed falls on them, not on the individual coders.