Steering Software Development with Priorities Instead of Deadlines
There is an unquestioned practice in software development which to me seems to be quite harmful. It’s the practice of letting developers work towards a deadline.
In this article I’m not much concerned with how the question „When will it be done?“ is answered. I’m just assuming that there is a deadline attached to a certain number of work items or scope because some decision maker needs to have one.
Given that there is a deadline relevant to a decision maker I want to propose to not tell the software development team responsible for implementing the work items about it.
Yes, that’s right: developers should not know when a certain scope is supposed to be delivered!
Benefits of not knowing a deadline
Is that possible? Let’s first look at whether this is desirable:
- Not knowing the deadline takes a lot of stress out of software development. Reason: Stress is induced by worry and fear. „Will we meet the deadline?“😱 Without knowing the deadline there is no reason for fear.
- Not knowing the deadline makes it easier to produce high quality code. Reason: Qualities for sustainable productivity (aka long term success) are easily skipped under stress. When facing a deadline developers focus on runtime qualities, e.g. functionality, performance. Automated tests, maintainability, refactoring are postpones indefinitely - which will lower productivity sooner than later.
- Not knowing the deadline leads to increased motivation due to a higher required level of trust. Reason: If developers don’t know a deadline they have to be trusted to work as focused as possible. Whatever they do must be the right thing to do to achieve the desired qualities in a balanced manner. When developers feel they are allowed to do the right thing and not work under growing stress they once again can have fun working.
Who wouldn’t want all that?
Please remember: I’m not saying there shouldn’t be deadlines anymore! I’m just saying to let developers know them is counter-productive. Knowledge of deadlines leads to all sorts of undesired behaviour, e.g. neglect of essential qualities, tunnel vision, student syndrome, following Parkinson’s law, or clocking overtime.
Prerequisites for not knowing a deadline
How can developers work towards deadlines without knowing them?
Don’t ask developers when it will be done!
First of all and very obviously developers cannot be asked any longer „How long will it take?“ Because once they answer the question they also know the deadline.
Development teams can and should be asked a lot of questions like „When did you start working on this item, and when was it done?“ or „What categories does this work item belong to?“ or „How many work items was this backlog item sliced into?“ or „How much does teamwork and/or technologies today differ from before?“ But teams must not be asked to predict their future performance.
Prediction is not the job of development teams but of decision makers. They need to observe (collect data), they need to become clear about how to handle uncertainties and risks (calculate probabilities). It’s important to them to meet a deadline? Great! Then they should do their homework.
How this can be done I’ve sketched out in previous articles like this one. Or you can read much more extensively about it in for example „When will it be done?“ by Daniel Vacanti.
Takeaway: Switch from estimation to forecasting.
For the point I want to make here it’s not that important, though, how a decision maker arrives at a deadline (except for not asking developers for an estimate). Sometimes the deadline is even given by a third party and is non-negotiable.
More important is the question what to do once the deadline is set? What to tell developers if not the deadline?
Telling developers the deadline essentially is offloading responsibility. Once developers know the deadline it’s supposed to be their problem to deliver on time. But as experience tells this does not work reliably. And most notably it never works in a relaxed, sustainable way. Motivation and code base quality get over-exploited.
Responsibility for meeting a deadline (or even anything) very fundamentally cannot be transferred, assigned, pushed onto somebody. Responsibility can only be taken, pulled by someone who feels in control. Since that’s rarely the case (subjectively as well as objectively) it should not be done by developers. The only thing a developer can control is her focus.
Continuously re-assess priorities!
What developers should know instead of a deadline is what to do exactly. What to achieve in terms of runtime functionality, and runtime efficiency is crucial. The more clear requirements are the more likely it is to meet a deadline.
Takeaway: Only accept deadlines if you really know what you want.
Clarity is not just about scope, though. It’s also about priority. Which of a number of clearly defined requirements should be implemented first, which second etc.? And how many resources should be put on a requirement: how many developers using how much of their time?
Most teams I visit are doing multi-tasking. Not only do the teams work on several items at the same time, but each developer has more than one item on his plate.
If prioritisation is about finishing some tasks earlier than others then the practice of multi-tasking surely has to be thought over. But as long as multi-tasking is still present each work item needs to be assigned a basic attention ratio: how much focus time (attention) to devote to a work item in relation to the available time. It surely makes a difference if an item is worked on 8 hours out of 8 each day or just 2 out of 8.
Priority then is expressed in the number of developers assigned to an item and their attention ratio. Priority thus is a tuple: (attention ratio, number of developers).
- The primary expression of priority is the attention ratio assigned to a work item. The more attention it gets the faster it will be finished.
- The number of developers is secondary, but surely more developers assigned to a work items means it’s supposed to finish faster or requires more attention in general right now.
Takeaway: Development teams should be led by priorities not deadlines.
„How many developers at least/most should work on item X to finish it most quickly?“ is a question to ask the development team. Which number to pick in that range and which attention ratio to assign, though, is a decision not to make by developers. That’s prioritisation and to be done by the role which needs to meet a deadline.
The development team then only gets told how many developers to focus for how much time on a work item - until the situation is re-assessed.
„Work on item A for 4 hours each day, and 2 hours on item B until finished or told differently. Engage!“ - that’s what a developer should hear. And then she diligently does her job as best as she can without hesitation, deviation, or repetition.
But of course things rarely flow smoothly. That’s why priorities cannot be fixed just once. They need to be changed in response to how development progresses. If some work item has priority (0.25, 1) today, it might move up to (0.5, 1) next week, and (0.75, 2) the week after.
Re-assessing priorities is the responsibility of the decision maker, too. She cannot just fire-off a „work item bullet“ and lean back, assuming it will hit the target right in the center (aka meet the deadline). Whoever is driven by a deadline needs to stay involved; that’s her job!
Continuously watch the progress!
Staying involved first and foremost means watching; watching how the implementation of a work item evolves.
Please note: Watching is not controlling! Watching is not micro-management. It does not mean telling a developer how to do her job, whether to write a test or not, whether to refactor or not etc.
Watching is observing, is inquiring as to why progress is like it is (slow or fast). Not more.
There are just two ways to speed up work on an item:
- remove impediments
- increase priority
And increasing priority should be done in this order:
- increase attention ratio
- increase number of developers working on it
This is in conformance with the Theory of Constraints (TOC) which states that bottlenecks (constraints) should first be exploited (remove impediments, increase attention ratio) and only later be elevated (increase number of developers).
Once the impediments are minimized, attention is maximized, and as many developers as makes sense are focused on a work item… things cannot go any faster. Knowing a deadline won’t make any difference - or if, then a negative difference.
Takeaway: Progress is maximized by constantly supporting optimal focus
Again: Whoever wants to meet a deadline cannot leave software development on its own. It needs to be continuously watched for changes in flow (or progress). And if things evolve in the wrong way then obstacles need to be removed and/or the priority needs to be adjusted. But no deadline needs, no, must be communicated.
Summary
I think it’s not only highly beneficial but also possible to isolate developers from any knowledge of deadlines. It follows a clear separation of responsibilities: some people are responsible for meeting a deadline, and some are responsible for producing quality code.
That’s two different goals. These goals require different skills. And they require different information. If information hiding means anything in software development then here’s a place to apply the principle: hide the information about deadlines from the developers. And likewise: hide the information about necessary refactorings or testing from decision makers concerned with deadlines.
The chaos prevalent in many teams - yes, also in teams calling themselves agile - needs to be attacked by drawing boundaries. Communication and transparency are good - except when they are not. In my view transparency in terms of deadlines is too much of it.
If software development is supposed to produce high quality in all regards in a constant flow, then developers should not know or care about deadlines but just about their focus.