Scrum is more than just iterative and incremental

People often talk about Scrum as if it were nothing more than an iterative, incremental development process. Taking just these two aspects of Scrum makes it seem like it would be easy just to bolt Scrum onto existing development practices and organizational structures. I have trained and coached and talked -- either in person or on discussion lists -- with people who were completely comfortable calling their functionally delimited, mini-waterfall processes "Scrum" or "Agile."

"Well, we deliver a release every month that builds on previous month's release," is a common refrain.

A few quick questions reveal what's actually going on:
"Great! How's your quality? Is it getting better with each release? Are your teams getting better? Does every release contain the most valuable features you could possibly deliver?"

"Um, well...." is the usual response when an organization has adopted the superficial qualities of Scrum while ignoring the deeper principles and the practices they inform.

Iterative and incremental development are two results of Scrum done well, not the essence of Scrum. So what, you ask, is the essence of Scrum? I believe Scrum is about building cross-functional teams that are capable of learning how to do better work every day. Focusing on working software as the primary measure of progress by making use of the Sprint and daily planning cycles and the Sprint Review (to show our work) provides the framework for technical innovation -- and more basically, getting the job done, which is a huge challenge by itself in most organizations. The Retrospective gives teams the mechanism to improve both their degree of teamwork and, to a greater or lesser extent, the organizational environment in which they work. Learning teams, when propagated and nurtured, produce learning organizations that have a built-in competitive advantage over their less dynamic competitors.

Scrum is also about letting go of false measures, unrealistic planning, and failed control mechanisms. Measuring team throughput (Velocity) rather individual utilization provides a realistic tool for planning. The planning itself changes from activity and milestone-based to feature- and value-based, using teams' demonstrated ability to deliver working software as the key metric. Having teams pull work from the top of a prioritized Product Backlog ensures that, by definition, the highest-priority features are being worked on at all times and that each release contains the highest-priority, and therefore most valuable, features that could be delivered. Finally, allowing teams to deliver features, instead of relying the thoroughly discredited industrial practice of externally assigned individual tasks, opens the door to creative solutions -- and breakthrough productivity.

Where does quality fit into all of this? Returning again to the agile principle of working software as the primary measure of progress, non-working, buggy, software cannot demonstrate progress and therefore cannot be called "done." Teams and organizations that hold true to this principle have the capacity to do truly amazing things in an industry too often characterized by the poor quality of its products.

This is by no means a comprehensive list, but for me, right now, these are the key features of Scrum.

All for now....

...-.-