‘They still want us to deliver too much in too little time!’

May 18, 2013

In a class, we had a large group of people from one company. The company is doing or getting close to doing mostly Scrum.

The managers and the Board have not attended a Scrum class.

In any case, ‘management’ is still asking the Teams to deliver too much in too little time. Both say the scope and the date are inflexible. At least, that is how it is heard.

What is the solution?

This is one of the difficult problems of our work. The answer is obvious, but not ‘easy.’

I think it boils down to this.

1. Customers want things quickly. Time itself has a value. For example, we must get to market with our new product before the competition.

2. On the other hand, as they said in Latin some 2,000 years ago, to predict is difficult, particularly of the future.

3. Working harder is almost never a good option.

4. Always we can work smarter. So, fix more impediments.

So, (the Scrum Team) must make predictions, and try to make them real. And everyone must understand that change will happen. And the variability in our ‘predictions’. When we think the next release will be done and how much will be in it.

These are not easy conversations, often. People misunderstand each other. Nonetheless, you must have the conversation.

Sometimes they say: we have a fixed time, a fixed scope and a fixed budget.

Fixed Scope. This is never completely true (in my experience). There is always some proposed small features or featurettes in the work that do not have to be done in the current release. This gives us an incentive to further break down the features, to identify small things to move to ‘later’.

Fixed Time. There is a value to delivering fast. Even before the current ‘date’ would be good. Often very very good. (Which gives us yet more reason to reduce the number of small features in the release.)

Fixed Budget. Usually cost is NOT the main driver. There is (or should be) a huge ratio between benefit and cost, so that being stingy about cost is silly. Especially when time is so important.

Lastly, in this too brief discussion, I must mention impediments. In Scrum, we want the Team to identify their biggest impediments. Things, if fixed, that could double (again) our velocity. Not by magic, not by working harder (longer hours), but by fixing impediments. In the wetware, in the random carbon units, in the automated testing, in the management culture, whatever. Often fixing impediments costs serious money, but provides even more serious benefits. So, we need good judgment to spend wisely.

Finally, we need to use Agile Release Planning to start to identify a reasonable scope and date, initially. As things change (and everything will change at least some), we can revise and revise and revise it, and do the best we can to innovate within the constraints.

Note: It can of course be true that we should stop this current work. It can be that: at our current pace, given the budget or the time constraints, we will never beat the competition to market with a good enough product. And this ‘giving up’ is good thing, since it allows us not to waste money foolishly, and hopefully re-direct it to a better purpose.

***

Managers must learn that if they pressure the Team (to deliver more in a given time), the Team usually hears two things:
(a) cut quality, and
(b) work high overtime.
So, the Team and managers (or customers) must talk about this.

Almost always managers do not want to reduce quality or cause overtime (eg, bad health, divorces). What they want is ‘creativity.’ Someone to cleverly see a simpler way to do things. How to remove an impediment. How to do fewer features. Something. Something unexpected that they may not have imagined without a challenge.

So, talk about this. Start to understand each other better. You need each other.