Scrum Is Not Agile

(and neither is TDD, XP, ...)
 
While I don’t know any of the original signatories of the Manifesto for Agile Software Development, I expect that the four values expressed come out of their experience building software. They certainly align with my experience doing same.

And that’s the first take-away: Agile comes out of experience.

Experience drives the development of a world view. Taken together, the manifesto expresses a way of looking at the world of software development. In that context, we can see that the manifesto is an expression of a world view that informs the way we go about exercising our craft.

Take-away number two is this: We don’t do Agile.

What we do is build software. When we find ourselves on a team with good developers, building working software that delights the customer, adapting to the ebb and flow of changing expectations, we are being Agile.

Software development is hard. Frameworks and practices like Scrum, TDD and XP are some of the tools we can use to help teams of motivated individuals deliver great software. But it’s important not to confuse the means with the end, and to keep the emphasis in the right place. It's no mistake that the first value in the manifesto is 'Individuals and interactions over processes and tools.'

Take-away three: Good software is built by teams of disciplined professionals. 

 

When an organization emphasizes process over people, it runs the risk of fostering a world view that delivering good software is a matter of magic. It's a world view that says "let's take some people, throw them into a Scrum-shaped box, wave the buzzword wand, sit back and reap the benefits!" To borrow an expression - "In John Scrum we trust."

Good software starts with good people. One of the principles behind the Agile manifesto is "Build projects around motivated individuals." If an organization wants to be 'Agile', it needs to emphasize strategies that foster and encourage its people to develop a world view consistent with the Agile manifesto. As a colleague of mine, Dave Moran, puts it: "Being agile is an organizational concern, not just something the development teams do."

In a prior life, I was a carpenter. Before starting my first job, I had my hand saws sharpened. A few days into the job, the foreman asked me to cut away a piece of wall framing. With newly sharpened saw, I jumped into the project. However, instead of cutting through the wood like butter, I was still sawing away when the foreman comes over and casually mentions that saws meant for cutting wood don't cut through nails. And then I realized that trying to cut through a nail produces a different sound than cutting through wood. Ugh! I felt a bit stupid but learned something that day. It was one of many experiences that shaped a world view that helped me become a good carpenter.

Scrum and other agile processes are tools like a saw. In the hands of a John Scrumer, the tool gets dulled and fails to deliver. In the hands of a disciplined professional, it will cut through impediments like butter, yielding working software that delights the customer.