Scrum Project Management as a Simple Rules Framework

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves" - Ken Schwaber and Mike Beedle, Agile Software Development with Scrum

The Scrum methodology is elegant in its simplicity. It teaches us that when processes are not stable, and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. We must rely on observation. We must adjust the processes as we go and guide them to create our desired outcomes. Using this philosophy as its basis, Scrum is founded on three simple principles: make everything visible, frequently inspect outcomes, and adjust the process as necessary.

People really like simple messages and Scrum delivers in spades. Scrum is easy to communicate and the practices are rather straightforward and easy to implement. You can put a single diagram on a single page and talk someone through pretty much everything you need to know. There is power in the simplicity of the message and that has been a major factor in Scrum's rise as the de facto agile methodology in use today.

The simplicity of Scrum can be deceiving. That simple, straightforward message comes at a cost. Scrum is not all there is to software development and it's not all there is to good project management. If we are fortunate enough to have a group of really great developers, a fully engaged product owner, and a team that can operate with some degree of independence from the rest of the organization; the simple messages of Scrum are a great way to lead a project. The quality of the team allows you to get away with a barely sufficient methodology.

What about when our context is not so simple? What about when we have to develop complex systems architectures or work with a tightly coupled legacy system? What about when we have multiple teams distributed across the globe? What about when our product is an integration of several different products, each with their own product owner? What about when we have to deal with procurement or complex human resource concerns?

Scrum is silent on these issues.

Scrum abstracts these answers behind the team's ability to "devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves". While we are beginning to answer some of these questions, Scrum doesn't really give us much guidance on how to pull it all together. There is clearly more to the story than Scrum is prepared to address.

You know what though? That's okay.

It's okay because Scrum is broad enough to provide simple rules for one set of problems and a framework to handle more complex issues (and incorporate more complex strategies) as our teams need them. The simple rules of visibility, inspection, and adaptation don't break down. They have no geographic boundaries. They don't care about the size of your team or the expertise of your team members. They are about how we are going to control our projects in the face of uncertainty.

Scrum is a barely sufficient, simple rules framework for developing great products. It gives us space to apply our knowledge and skills and the freedom to adapt to our surroundings. We just need to be aware of what Scrum leaves out and be prepared to fill in the blanks. That said, I would rather be given a framework for adaptation than a heavyweight methodology. Very seldom in software is there one best way to do everything. Our processes should not assume otherwise.