The Power of Scrum Doesn't Lie in the Scrum Team

Part of the reason that agile development is so attractive to decision makers is that it gives the impression that more work can be done to a higher quality, with greater customer satisfaction, without increasing resources. And in one sense that's correct; after all, why would people use scrum if it didn't have at least some of these benefits?

But the rationale behind this impression sometimes seems to be that implementing scrum within the development team will produce the results and that everyone else can continue working in the same way as before - in other words, the power of Scrum lies in making development work as a scrum team, because that is where the efficiencies are to be made.

This is not correct.

A scrum team can indeed be a powerful force for productivity.  If a multi-functional team of people attack the user requirements in an organised and efficient way, then like a team of carnivorous beetles they could swarm over a backlog, devouring whatever work was in front of them and passing out sections of the deliverables until the bare bones of the sprint are picked clean and they can move onto the next one. In this scenario there certainly are efficiencies to be made and more will be produced without having to increase resources.

(On a side note, multi-functional teams don't exist in reality, but that's for another post.)

And what will the scrum team produce?  They'll produce what the Product Owner has said is the highest priority, a collection of tasks that together make up a deliverable iteration.  But so what?  You can have the most efficient, skilled, experienced demolition team in the world, but if they knock down the wrong building, who cares how efficiently or cleanly they did it? The productivity of the scrum team is absolutely irrelevant to the measurement of the most important aspect of scrum: Does the customer get a more appropriate deliverable than if you'd used waterfall? 

(I totally get that the increased productivity of a scrum team, as measured in its velocity over time, is an important factor in choosing to "go scrum" because this velocity is seen as improving time to market, which is a key goal for many companies.  My point is that it doesn't matter how quickly Betamax got to market, what mattered was that people didn't want it.)

By contrast with scrum, Waterfall's great strength is its attention to detail, the fact that everything is locked down at the start.  Yes, this means that by definition it is not agile and therefore if the specification changes this can cause serious budget and time overruns, and in theory developing in sprints ameliorates this problem almost entirely.  But agility in the scrum team on its own won't produce a better deliverable for the customer.  Remember that the scrum team is the means of production, not the decision maker about what actually gets produced.


The power of scrum lies in the ability of the Product Owner to change the direction of the scrum team's production by changing the priority of work items on the backlog.


So if you're having problems giving customer what they want with Waterfall because the specifications keep changing, that isn't going to stop just because the team produces in iterations.  It will stop when the analysts, project managers, designers and Product Owner work together in an effective and efficient manner to identify these specification changes as they happen and re-prioritise the backlog in real time accordingly.  If the backlog isn't looked after by the Product Owner then the scrum team can produce wonderful code that does entirely the wrong thing, which is hardly an efficiency improvement.  To paraphrase a slightly ruder saying, "Rubbish In, Rubbish Out".  A scrum team that isn't directed to produce the right things will produce the wrong things, and the deliverable to the customer will not be any more appropriate than it was with Waterfall.  

This leaves us with a significant and often overlooked point: it's the quality of the client-company communication and how that is handled by the Product Owner which drives the power to the scrum team.  And if THAT'S handled well, then quality gets better, deliverables get more appropriate and the scrum team starts to make worthwhile efficiency savings.