As we’ve discussed elsewhere on this site, and ad infinitum on Twitter, a lot of people complain about Scrum’s Sprint, the short week or two within which the team is expected to take on a goal, select some backlog items, build a new version of the product that achieves the goal.
Let’s consider the Scrum Sprint. What’s the strongest case we can make against it?
We’ve already talked about the fact that Sprints are not necessary to teams who are working well: pulling one story, and swarming on it, then another and another, works better, my friends and I believe, than Sprints. (There are good reasons to continue a regular cadence of planning, and certainly of review and retrospection.) But that’s not much of a case. What else ya got?
For beginners, Scrum’s Sprints are supposed to constrain the team into learning how to get something “done” against a deadline. Practicing this over and over can help a team immensely, up to and including meeting real deadlines. However, the “walking skeleton” or “do one small story” approach works at least as well, and perhaps better, for teaching this way of working, at least for teams with coaching. Even so, the difference isn’t immense. It might be enough to sway us but it’s not enough to really convict the Sprint and put it away for a long time. Here again, not enough of a case.
But what about this?
In many companies, management believes sincerely that their people need to work harder, to get more done. They believe that people need “stretch goals”, or as I call them “failure goals”. They believe that people need to be put under pressure so as to “enable” them to “perform better”. They’re sincere about this. It has worked for them, they think, so they’re going to continue to do it.
Now, if these managers were properly educated, they wouldn’t think this. They’d understand pull versus push. They’d understand limiting WIP rather than increasing it. They’d understand true delegation, true leadership, and so on. There are many ways they could learn those things – and the managers we’re talking about have not learned those things, and they’re not learning those things.
But they have heard about “Agile”, and about Scrum, and that it’s supposed to give you “Twice the Work in Half the Time”, and they want some of that. So they send their people to CSM school or PSM school, and they tell their teams from now on we’re using Scrum, gang, go for it.
The really great thing about Scrum, from the viewpoint of this kind of manager, is that instead of waiting months to see the results of a software effort, you can examine the team’s work after every Sprint. In fact, you’re supposed to review their work after every Sprint.
This is great!
So management comes down at least every couple of weeks, examines what the team has done, finds fault with it, puts pressure on them to do more and better. They demand more stories. They’ve been told they’ll see twice the work and by god they’ll have it!
Actually, no, this isn’t great. Scrum has increased pressure on the team. It has been rammed into place without a real chance to deliver the real benefits of Scrum. It has been planted in soil so bad that the fruit is going to come out rotten. People suffer.
A team with a coach wouldn’t make this mistake for long, because the coach would sit down with management and sort them out. Scrum asks the CSM to do the job of educating the company’s managers and product people in Scrum. But a CSM with two days of training isn’t equipped to do this, not at all.
Putting Scrum in place in an organization with an attitude of managing by pressure, of working hard to get more things done, makes the lives of the team worse and provides little or no value back to the company.
This result is common. It’s possibly the most common outcome in organizations that are starting Scrum with no help other than some CSMs with their two days of amazing training, or PSMs ditto.
Frankly this result is almost inevitable. In companies with this kind of management style – that is, probably, most companies – Scrum’s Sprint is harmful to actual human beings.
How’s that for a case?