I’m a big fan of things that make sense. Simple explanations, using metaphors to explain the otherwise inexplicable, incorporating landmarks into driving directions and splitting up large projects to get them done faster are all concepts with which I find favor.
This is why, when I first learned about Scrum, it seemed like a valid way to develop software faster, or at least more efficiently. In my mind, it made sense that if you were to build multiple parts of a single application simultaneously and then bring them together, the final product could be built much faster.
I am not alone in this belief. Noted business author and contributor to Forbes magazine, Steve Denning, recently espoused his appreciation for Scrum, commenting:
“If there was a Nobel Prize for management, and if there was any justice in the world, I believe that the prize would be awarded, among others, to Jeff Sutherland, Ken Schwaber and Mike Cohn for their contributions to the invention of Scrum.”
While I may not hold it in as high a regard as Denning does, Scrum does warrant recognition for its revolutionary approach to speeding software to market; but even fans of something – be it a baseball team or a development methodology – know that the object of their fascination is not perfect.
The Scuttlebutt on Scrum
The core practices of Scrum are 10 basic tenets of employee management and motivation that you would…or rather should find in any corporate setting. And yet these practices apply particularly well to software development teams. Those practices, as Denning outlines in his article, are:
- Organize work in short cycles
- The management doesn’t interrupt the team during a work cycle
- The team reports to the client, not the manager
- The team estimates how much time work will take
- The team decides how much work it can do in an iteration
- The team decides how to do the work in the iteration
- The team measures its own performance
- Define work goals before each cycle starts
- Define work goals through user stories
- Systematically remove impediments
Denning goes on to point out that while none of the Scrum practices is new, the revolutionary aspect of them is how they are brought together and work in concert to form a disciplined manner of getting work done. When Scrum works, it can be twice as productive as other methods. Unfortunately, it doesn’t always work to perfection.
As Denning points out, “More than 70% of Scrum implementations have failed to achieve their goals.” He attributes a portion of Scrum’s high failure rate to half-hearted implementations of Scrum or breakdowns in the Scrum core practices, noting in particular those that come from corporate hierarchy not wanting to relinquish control of project management, namely bureaucratic interference and team interruptions. He notes that all too often, such things derail projects by setting asunder the harmony that Scrum’s core practices are designed to establish.
Nevertheless, as Agile early-adopter Laurent Bossavit recently noted in his piece on InfoQ on the occasion of Agile's 10th anniversary:
It is easy to rail against "half-assed Agile" and "ScrumButs" and give in to the temptation to blame the victims - to hold it against the students that they failed to understand something that was poorly explained, rather than hold the master responsible.
And that is where I part company with Denning because he overlooks the fact that even when Scrum is left to its work and it follows the core practices, there’s more that needs to be done to ensure success.
A Scrum Concerto
Using an orchestra as a metaphor, it takes more than just following the music to make harmony. All instruments must be “in tune” and the various instrumental sections need to be brought together in an adroit and sensible manner that results in a whole that is greater than the sum of its parts.
Similarly, with Scrum, it takes more than harmonious existence to create structurally sound software. Not only must a Scrum ensure that the code being written is structurally sound, but also that the foundation software being built upon is also solid. It also means that each Scrum dynamically analyzes its portion of the project, then when the various Scrums bring their pieces of the project together, assessments are also made to ensure each can be integrated seamlessly with those developed in other Scrums.
So aside from following the 10 core practices, Scrum can be even better if those using it would take the time to focus on structural quality through automated analysis and then further analyze the integration process to ensure a flawless final structure. In doing so, the structural quality of application software developed in Scrums would improve, the time it takes to reach optimal quality application software decreases – through the elimination of maintenance and technical debt – and Scrum can be something worthy of recognition by the Nobel Prize committee…at least in Denning’s eyes.