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.

You’re Unique, Just Like Everyone Else...

When I'm helping to coach a new team toward Scrum adoption, probably the most common objection I hear is something along the lines of, 

          "Yeah, well… Scrum is fine for you. But my 
          [team|project|company|product] is really incredibly special
          and completely unique in the world.  An out-of-the-box
          solution like Scrum just wouldn't work for us." 

I think this objection most often comes from the all too common misconception that Scrum is somehow tied to a technology, type of product or a certain pool of customers.

While it is true that most organizations successfully applying it today are software engineering firms, it is equally applicable to the local chapter of the PTA, automobile manufacturing and biochemical research. At its core, Scrum is a set of three characters, three rituals and three relics that each team contains or produces. In much the same way that basic laws governing traffic apply equally to all types of motorized vehicles, so these nine pillars of Scrum can be applied to your team. It can launch your team toward hyper-productivity, improve the lives of team members, give everyone a deeper sense of accomplishment and make your customers happier than they have ever been.

I recently had such a conversation with a colleague who insisted that his team could never utilize Scrum because he does research. We happened to be standing beside a whiteboard when he raised the objection so I began to interview him about his tasks and write them up on the board.

• "What are you researching?"
• "Are there a lot of research items waiting for your attention?"
• "Can you describe to me how you go about your research?"
• "How do you know if your research is heading in the right direction?"

In under ten minutes of interviewing him, I quickly learned that he was already applying a basic set of rules and processes to all of his research items regardless of the goal or subject. When I enumerated them on the board for him, his eyes widened and he said, "You mean those are my Scrum stories?? Wow. That's so cool!" Once he got that Scrum wasn't trying to tell him what to do or to micromanage his tasks, his mind opened and he saw how useful it can be to create the transparency and collaborative atmosphere that Scrum brings to a team.

So if you, like my colleague, have been struggling to understand how the rules of Scrum apply to your product, take a deep breath and relax. The fact is, they don't. They do, however, apply to the team that creates the product and the way they go about their work.

Introduction to my Scrum Blog

I have been in the Software industry for over 20 years now and have served at all levels of an organization. I started out as a Database and Unix System Administrator then moved into Software Engineering (Associate through Senior Software Engineer titles). I have been a Development Manager, Project Manager, Vice President of Engineering and Chief Architect. I also spent several years either moonlighting or primarily employed as a C Instructor, was a Microsoft Certified Instructor of C++/MFC and Win32, and taught Unix Shell Script Programming and Unix for Users and System Administrators.

I have worked with some of the best, and with some of the worst. I have been in healthy organizations that were very happy, empowering, educational and sometimes even inspirational places. I have been in "bleeding edge" companies, high profile security, obscure infrastructure and once even accidentally stumbled into a position with a spammer (I quickly left).

I have also been in the pits of hell from death marches, survived micro managers, outlived absentee managers, endured ego-maniacal architects, suffered with dishonest Product and Marketing Executives, bolstered battered QA engineers and even coached some very senior engineers with diva complexes into better behavior. I won't say that I've "seen it all" but I will say that it's rare that I see something new.

Frankly, although I have worked in some high profile companies that most people would consider to be very exciting, it has been a long time since anything in the tech industry ignited my passions. But recently I stumbled upon something that has my creative and energetic juices flowing again. It's a process that can improve not only the efficacy of any team of people with a goal but, when properly applied, it simultaneously improves the lives of the team members and the satisfaction of their customers. As you may have guessed from the name of this account and the title of this blog entry, I am of course talking about Scrum.

I am currently serving as the Master Scrum Master for a large and growing company that is striving to make both the structural and cultural shifts toward Scrum. It's not a path without pitfalls, to be sure, but I wanted to start this blog to track our progress, address issues we encounter and share war stories to help others who may be similarly engaged through what can be some treacherous waters.

So welcome to my blog. I hope you find it informative and useful, and I look forward to hearing your thoughts on my musings, too.

Cheers,
Scott