There are times for every client when their development team takes on something that they cannot deliver. Regardless of the size of the organization and the project. It is usually everyone’s fault and no one’s fault.
When a software development project does not go as planned – and this is what normally happens in a classic environment (not even remotely Agile) –, the management automatically wants to pressure the team to make up for lost time. But software development is not a production story where you can “push machines to their limits”.
Software developers try to deliver results in a knowledge-based economy, and as such are highly exposed to the volatile situation where there is either inspiration or no inspiration, or there is certain knowledge or no knowledge. It often takes some research to find a solution.
It may easily be the case that we do not choose the best solutions because of a lack of routine, which in turn means that we have to rewrite parts of the code, code review becomes longer (if it exists at all!), or we accumulate technological debt with our decisions that compromises the sustainability of the software.
In short, operating in a knowledge-based economy is very much subject to the capricious and volatile human knowledge, intuition, inspiration and routine.
Pressure
If a software development team is under pressure from the management because they see or feel that they are falling behind schedule, the natural consequence is that the team will go into defensive mode and promise everything they think is expected of them.
Obviously, this promise has no real basis, but that doesn’t at all bother the management that doesn’t understand Agile. They do not ask what this new, twice as much commitment is based on, when they could not even deliver the previous one.
And there are reports! But they cover too-long periods of time or too many steps to enable excellent management decisions when and where they are most needed.
Upon a delay, under pressure, the team promises: “Oh! We will deliver twice as much as before…” They will try, they will work overtime, they will work on weekends. The only thing no one has dealt with in this situation is the volatile context of “knowledge, routine, intuition, inspiration”.
Thereby they will certainly make more mistakes and deliver even less. Inevitably, not even as much as when they didn’t promise as much.
The management will happily keep going with increasingly unfounded promises. But these promises are actually extorted promises. Their sole, undeclared purpose is to drive non-management colleagues into a position where they can be blamed later. It is mean, even if it is sometimes not the result of conscious intent. However, I have seen too many times that it is a deliberate tactic by management.
There are no miracles
Management, satisfied with the promises, expects to see a miracle by the new deadline and expects the team to deliver twice as much indeed.
Of course, the miracle will not happen.
In fact, a lot of time has passed again, and between the two “milestones”, no one has received any useful feedback to support decisions. There is plenty of communication. For example, “James has already got sick from working overtime”; “Robert has been dumped by his girlfriend”; “Mary’s lumbago has recurred because of stress”.
The phenomenon of stress and burnout is not really addressed by management beyond the level of superficial communication. The point is to make up for even more lost time with even more effort! The vicious circle is thereby complete, and the team and the project are heading towards total failure at the speed of light.
I want to know, I will be a Scrum Master
The resolution
There is a solution.
Never ask the team to promise anything… without justification! I don’t care what the team thinks I want! I don’t care if they can find out my secret thoughts and desires! I don’t care what promises they try to dazzle me with, because I don’t believe them anyway!
What can be done then?
Once the team has learnt not to make promises, they can learn to make commitments instead.
Let me illustrate the difference between a commitment and a promise: “Darling, I’ll take you out to dinner tonight!” This is a commitment. If you breach this commitment, you justifiably incur wrath.
No one mentioned whether this dinner will be at the gyros stand on the corner or at a fancy restaurant. This latter is the promise. If we go and have dinner at the gyros stand on the corner, the commitment is fulfilled. Is it up to the expectations? Who said anything about expectations?
Let’s stop making promises and start practicing commitments.
Implementing the culture of commitment
The first step is to start transparent operation around the team to see what the de facto performance of the team is over a given period of time. Think in terms of one-week intervals.
To start practicing commitment, we first need well-defined tasks.
In 99% of cases, teams that management says only promise and never deliver on time have no well-defined tasks, only the illusion of them.
They are not given sufficient time to deal with the uncertainties and risks of the needs and to get meaningful answers to their questions. If management leaves the team on their own, saying, “You’ve got the specification, break it down”, project failure is certain.
All my experiences so far have shown that the busyness of management/business decision makers is the main reason why a team is not able to work with well-defined tasks (business needs).
As such, they cannot make commitments either. There is nothing to commit to. But unfounded promises remain. Not because of the irresponsibility of the team, but because of the incorrect operation by the management/business decision makers.
The well-defined task
A task is well defined if a developer in any country, under any circumstances, can read the task and know what to do. At code level. This is a very complicated and expensive process. That’s why we don’t make more of it than we absolutely need for the next shortest development timeframe.
If we have learnt to write well-defined tasks, and learnt to talk to each other about well-defined tasks in a completely neutral and professional way and environment, then we have a chance to make a commitment based on our actual measured performance from the past.
If we do not have such preliminary measurements, we have to look at how many well-defined tasks the team has completed in a week. We won’t need more information than that for a while.
If I know that a team has completed, let’s say, eight well-defined development tasks in a week, I also know that I probably won’t need more than 8-10 well-defined tasks next week. So that’s how many tasks I need to produce in advance. Once I’ve done that, and we seem to run out of tasks before the end of the week, we plan and write some more! So what?!
We never spend significantly more or less time defining tasks together with the team. From there, it will be predictable when and how much resources I will have to set aside to define tasks correctly, on the part of management, business decision-makers and the team alike. I may not narrow down the range of actors! I may not spare this effort!
I like it! I want to be a Scrum Master!
Keep calm and progress!
The team managed to deliver 8 well-defined tasks last week, so do not expect more next week!
And if they ask the question, “What if we can only complete, let’s say, six next week? Because these well-defined tasks are bigger and more demanding in terms of work intensity than the ones from the previous week”. That’s fine too! Then we know in advance that there will be 6 for this week. And this is a commitment! This is not a promise!
For a commitment to be completed with the highest likelihood, the team must be relieved of having to deal with anything other than well-defined tasks.
The team can get involved in anything else only if:
- You have completed the commitment earlier and agreed on what the next task will be,
- You come across information that makes it necessary to change what you have agreed. Of course, it is mandatory to consult with the management and business decision-makers in this case as well. Directly and immediately!
Whatever the task is, it must be broken down into well-defined tasks before the team can start. We cannot spare this step in a crisis management situation either!
The actual performance
After three or four weeks of working with well-defined tasks and measuring correctly, the teams mostly find the average of their own actual performance.
It’s quite possible that this speed will not be enough to get the project done on time. This is fundamentally a fault on the management side. You may have an 800 page specification, but 800 pages cannot be planned (economically!) at a well-defined task level. And it is certainly full of gaps and logical inconsistencies.
Such a project is bound to get off to a bad start:
- We did not properly assess the risks
- We incorrectly identified the knowledge base needed to complete the project
- We did not select the right amount of people with the right skills
- The team does not – could not – have real performance monitoring
See our blog post “Why backlog is better than specification”.
If the possible is not enough
If the team has successfully got to the point where it is aware of its own performance at least a week into the future, and the management thinks that this is not enough for salvation, then there is nothing wrong.
We use the relative estimation method to see how far we would miss the target.
Let the team deliver along the lines of its real performance, commitment, through at least four iterations. Let us then look at how the progress made in this period compares with the expected size and complexity of the tasks ahead.
Relatively cheaply, we can judge how much harder or easier the tasks ahead will be compared to the period under review, and which elements we cannot even judge without further analysis.
What we can judge has to be simply multiplied by the numbers of the measured period. This is a very cheap and quick way to get a solid picture of how the project is likely to develop.
The relative estimation task should be performed regularly!
Forcing commitments, like promises, is unnecessary. It only puts the project and the health of our colleagues at risk.
Commitments can be made by a team if:
- They know their own capabilities and abilities.
- The management supports them in identifying these.
- There are measurements that objectively indicate if they are overcommitting or under-committing.
