Is the Scrum Framework Lacking?

What does it take to succeed with agile? When we first started with agile development, we a sent a couple of people to an agile conference, and they returned with advice from others that we should expect to take about “two years to get it right.” We shook our heads and wondered why. After all, we had selected Scrum as our framework, and it seemed simple enough.

As we discovered, there is some real change lurking beneath that simplicity. The current Scrum Guide states that Scrum is:

• Lightweight
• Simple to understand
• Extremely difficult to master

Adopting agile means more than adopting a simple framework, it means adopting a different way of working and interacting that involves some very real change. It is the change that is difficult to master, not the framework.

The Scrum framework is carefully and thoughtfully constructed, providing well-defined roles, events, artifacts, and rules that serve a specific purpose and are essential to Scrum’s success. However, there is a critical difference between the February 2010 Scrum Guide and the July 2011 version of the Scrum Guide. In the July 2011 version, Jeff Sutherland and Ken Schwaber state that, “…we have attempted to remove techniques or best practices from the core of Scrum. These will vary based on circumstance. We will be starting a ‘Best Practices’ compendium to offer some of our experiences later.”

Jeff and Ken have kept the Scrum Guide focused on the framework itself, but as everyone experiences, teams need more guidance than what the framework has to offer. It is frustrating to make the same mistakes that others have made because the information was lacking up front. Having teams independently discover – or rediscover – techniques may help to cement learning, but in this information age that is an archaic approach.

I’m glad to see that Bruce Winegarden has taken up the charge to capture more explicit rules as he states in his recent post, Kick Start Scrum with Explicit Rules. I’ve observed Bruce in action as an agile coach, and teams that he has coached have certainly benefited from his advice. And I agree with his point that there is value in stating more explicit rules as a starting point – provided there is knowledge-sharing about why these rules exist in order to convey a full understanding of their purpose.

Change exists on many fronts in agile adoptions, like the mindset and behaviors of management and how work itself is approached, but being successful at a team level is a critical step to gaining acceptance at a broader level. I look forward to hearing more from Bruce and his thoughts on agile development!