Why is Scrum “Extremely difficult to master”?

August 8, 2011 at 10:45 am | Posted in Blogroll, Scrum and agile, Software Engineering | Leave a comment

Scrum is developed and sustained by Ken Schwaber and Jeff Sutherland. Recently in July 2011 they have published on Scrum.org latest version of the Scrum guide, which defines the Rules of the Game. While I was reading it, one statement caught my attention.

“Scrum is lightweight, simple to understand (but) extremely difficult to master”. It is quite a bold statement and yet captures the reality quite accurately. I was interested to know why they feel so, but they have not elaborated it any further in this guide. Still it is quite important for us to know because if we try to figure out why it is difficult to master, it will help us to get over the difficulties and derive maximum benefit from implementing Scrum in our projects.

As I read the guide carefully, I found some pointers which we can collectively use to gain a better understanding of the issues involved. I am quoting below relevant portions from the guide, not necessarily in the order in which they appear, but grouped suitably to help interpret them better.

Let’s start from the top,
“The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must convince the Product Owner. No one is allowed to tell the Development Team to work from a different set of priorities, and the Development Team isn’t allowed to act on what anyone else says”.

This is easier said than done. Those stakeholders (chickens in Scrum vocabulary) who are powerful / influential / vocal / trouble-maker are used to having their way and would strongly resist / derail any attempts to take away their freedom. The top management needs to put its foot down and make clear to all concerned that the above rules related to product owner’s authority & responsibility are in the interest of the organization and hence must be strictly followed. Once everybody accepts and starts practicing, it will become part of the organization’s culture.

The team also needs to have a major mindset change,
“Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint”.

This is challenging both for the team members and the team leaders. The team members are so used to the planning & monitoring work being done by the team leaders that they feel it an additional overhead where they are expected to do it themselves. They also feel threatened as the responsibility for any failures would be now on them. They try to find ways to sabotage the new way of working by quietly continuing the old ways.

On the other hand, the team leaders suddenly feel the loss of power and are also interested in continuing with the status quo. This combination makes it very tough for the Scrum master to protect and support the Scrum practices and it takes a very persuasive and determined Scrum master to pass the initial phase successfully till the team members have tasted the new freedom and understand the benefits to them. In this phase the Scrum master also needs understanding & support from the management.

For the organizations who believe in process-driven way of working, the empirical nature of Scrum is difficult to digest,
“Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk”.

This tentative approach is unsettling for those who strongly believe in setting the standards and controlling variations. They use data to control & minimize variations; whereas Scrum uses data to learn from experience and adapt future course of action. For example, traditionally the data about time spent on doing different tasks is collected and analyzed to control effort variance; whereas “Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date (of completion) are the only variables of interest”.

At first glance it may appear that Scrum is neglecting useful data but it makes sense when we see it in relation to other scrum concepts & practices like self-organizing teams, transparency and learning from experience during retrospectives. The team members are encouraged to realistically indicate on a daily basis the remaining time for a task, without fear of being questioned even if it higher than originally estimated and making the actual status of the project known to all concerned. The visibility and transparency coupled with fixed date & scope of completion set in motion the corrective actions that are far more powerful than analysis of effort variance much later. The sprint-end retrospective gives an opportunity to the team to learn from such cases of poor estimation.

Lastly, there is a misconception that following an agile approach means you are free to use some parts of Scrum which suits the team and conveniently avoid the tough discipline in the name of tailoring; whereas Scrum says “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices”.

To master Scrum, all those involved directly or indirectly have to understand the implications mentioned above and accept short term inconveniences to get the long term benefits. Scrum can be highly successful when that happens. Otherwise if it is adopted because it is the new fashion, it will be worse that what it was before Scrum.

Each of the Scrum practices is simple and easy to understand. The real challenge is to grasp them in totality. It requires synthesis, not analysis. It requires a mind which is open to explore experiment, learn as well as unlearn. There comes an ‘aha’ moment when suddenly everything falls in place; that is the beginning of mastering Scrum.

 

Advertisements

Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: