In a class, we had a large group of people from one company. And the company is doing or getting close to doing mostly Scrum.
But the managers and the Board have not been to a Scrum class.
In any case, ‘management’ is still asking the Teams to try to deliver too much in too little time. And say both the scope and the date are inflexible. Or at least, that is how it is heard.
What is the solution?
This is one of the hard problems of our work. There is no easy answer.
I think it boils down to this.
1. Customers want things quickly. And 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.
So, we (the Scrum Team) must make predictions, and try to make them real. AND, we must get everyone to understand all the changes that will happen. And all 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. Usually. People mis-understand each other. Nonetheless, you must have the conversation.
Sometimes we say: we have a fixed time, a fixed scope and a fixed budget.
But always 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 break down the features smaller, so we can identify small things to move to ‘later’.
Always there is a value to delivering fast. Usually, even before the current ‘date’ would be real good. Often very very good. (Which gives us yet more reason to reduce the number of small features in the release.)
And usually cost is NOT the main driver. There is (or should be) a huge ration between benefit and cost, so that being stingy about cost is silly. Especially when time is so important.
Lastly, in this too brief discussion, we must mention impediments. In Scrum, we want the Team to identify their biggest impediments. Things that, if we fixed them, we could double (again) our velocity. Not by magic, not by working harder, but by fixing impediments. In the wetware, in the random carbon units, in the automated testing, in the management culture, whatever. And often fixing impediments costs serious money. 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. And, 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 in the time boxes we ultimately decide to give ourselves.
***
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 the managers do not want reduce quality or overtime (bad quality of life). 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 we might not have imagined without a challenge.
So, talk about this. Start to understand each other better. You need each other.