It's a Process, Not a Faith

Too many people approach Scrum like a religion. It's as if they believe that repeating some mystical lines from Schwaber's book will transmogrify the team. They move Post-It notes around a board but fail to communicate or clarify anything in the process. They draw charts but don't know their velocity. They estimate in story points but track in hours. In short, they have missed the point and are generally a danger to your organization.

The truth is that shifting an organization from a non-Agile methodology to Scrum is not for the faint of heart. It is a long, arduous and risky endeavor but pays exponential dividends to the successful. It requires a uniformity of purpose and mission clarity at every level of the organization and, for established organizations entrenched in old methodologies, it requires a strong, assertive and intuitive Scrum Coach. But whether you choose Scrum, Waterfall, XP, Lean or another methodology, your success still derives from good people, strong leadership, clear vision and commitment to excellence.

In "labs" around the world, Scrum has been tested at length and in a wide variety of organizations. Though it can be misapplied and half-hearted attempts do lead to failure, it has proven to be a remarkably successful process for human organization. It also increases the quality of life of everyone involved with the organization, from the customers to the CEO, when correctly applied. The data and success stories are overwhelming and measurable.

Here's one for you software engineering types out there.

Instead of religious ferver, how about we approach Scrum as a scientist would? Let's insist that any theories be justified by testable facts and metrics. Let's gather and review data, comb it over for anomalies and perform experiments to see where the boundaries of the theory break down. And that's the thing... There is already a lot of good news!

Does that mean Scrum will work for you? No.

But can it work? Almost certainly.

When a piece of software fails, which is more likely at fault?

• The Programming Language
• The Engineer
• The Computer

The answer is, of course, B: The Engineer. Making syntax mistakes, misusing constructs or failing to grasp the larger concept set forth by the language leads to horrific code and non-functional applications. It reminds me of the early days of Object Oriented Programming, and how C programmers would pick up a C++ compiler and work all manners of mischief on the code. I remember frequently seeing C programmers create an object then fill up the Constructor with C-style, procedural code. It was nauseating.

Taking an organization to hyper-productivity with Scrum is much more algorithm than incantation. Instead of considering Scrum to be magic or religious, consider it to be like a new programming language. Any language brings with it "must" and "must not" rules that, when applied correctly, yield the benefits of its specific strengths. In this case, however, we're programming organizations instead of computers. When companies adopt Scrum top-to-bottom and follow its "linguistic" rules, we see time and again that they uniformly begin to over-perform.

And be wary of charlatans who encourage you to try a few parts of Scrum but retain the old structures and procedures for the rest. They will most often reveal themselves by saying something like, "Let's compromise. We'll have daily stand-up meetings and give you a backlog, but we won't do planning meetings, observe Sprints, perform retrospectives, or track our velocity." It may seem like an incremental win but be warned: successes will be attributed to the compromise, failures will be attributed to the parts of Scrum you're using and this, my friend, is how you wind up with "Hello, World!" in your constructor.