Microsoft and Scrum

July 18, 2011 Categories Professional Scrum Developer .NET, Scrum, Software Development 37 Comments

I read a recent entry from Brian Harry’s blog on the next Visual Studio release, with a Scrum template and tool support. Brian is Product Unit Manager for Team Foundation Server and a Microsoft Technical Fellow. He also led the charge to use Scrum throughout TFS and has been instrumental in the inclusion of Scrum on VS 2010.

However, in his blog he has misinterpreted or misunderstood some key Scrum and Agile concepts. Many people do the same, but Brian’s influence is widespread and seen in the implementation of Microsoft products. I feel a need to address these conceptual flaws.

I’ve been nervous for a while about how well people would understand self-organizing Scrum Teams and the development teams within. Our tendency and tooling from waterfall and predictive processes is to view people as assignable, parsed, optimized resources. This works great if you are running a factory line and people are doing simple work. It really sucks if you are trying to do creative, complex work where there are many competing ideas and solutions emerge from interactions. The Agile Manifesto reflects this in “Individuals and Interactions over Processes and Tools.”

The new VS measures a person’s available capacity. You have to wonder. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed.  Scrum and XP are sneaky. A team of people sign up to solve problems within a Sprint. They are engaged in group problem-solving for the duration, and the problem never leaves some part of their brain. They are engaged. Brian’s comments and the consequent tooling reminds me of ideal days: a person is only working when his or her fingers are on the keyboard.

Last, but I’m sure I’ve missed others, is the idea of “assigned” work. This is a common smell of a development team that is not self-managing. Who “assigns” work if a development team is self-organizing? Development teams select work, figure out how to do it, and go do it. Assignments are a dysfunction.

In my measurements, self-organization is a prerequisite for Scrum and Agile productivity. This is where the 100%-plus productivity occurs not to mention the creative ideas, enjoyment of working, and quality.

Dr Jeffery Liker, author of “Toyota Way,” estimates that only a very small percentage of US Lean adoptions include its core principle, respecting, valuing and engaging the workers. There is a very tricky understanding between Scrum and non-Scrum. If we continue to apply the principles of directed, supervised work we are doomed to Lean and Scrum being another fad, another cover for a continuing use of Scientific Management and its management practices.

Many organizations have not adopted the self-organizing, team-based aspects of Agile. They still are predictive, top-down organizations. Tools that don’t support this function are hard to sell. However, form follows function. If we continue the same predictive manufacturing model, wrapped in Scrum tools, we as software professionals will have a very hard time rising to the increasing demands of our world for creative, sophisticated, quality products.

Scrum without self-organization and empowerment is a death march, just like waterfall, but an iterative, incremental death march without slack.

Also, the blog extols continuous flow. Now, I’m all for continuous delivery. It allows time for competing ideas, exploration, and emergent ideas. However, continuous flow is a Lean manufacturing technique, best formalized by Kanban. It is great for complicated work, such as service tickets, customer complaints, and some bug fixes. Kanban  is a very specific set of techniques from Lean that is applicable when the work is inherently simple. The work also may have been simplified, through standardized techniques, requirements description, or assigned roles. This is complicated work (where more things are known than unknown), not the complex work Scrum is designed for (where more things are unknown than known). Only the most sophisticated Scrum organizations have gotten to this type of work normalization and flow of work on products.

I’ve seen continuous flow touted as a simpler Scrum. It isn’t. It is another process for different types of problems. Waterfall was a simpler process for complex work: its failure rate indicated that it was inappropriate. The same failure rate will occur with Kanban as applied to the complex work of software development.

Jeff Sutherland, myself, and the Scrum community are updating Scrum with “Scrum Guide 2011” on July 21. It contains some significant and subtle changes. These changes build on the core principle of people being the value in organizations. The thought path Microsoft is following continues the old path of people being micro-managed, interchangeable resources.

I’ve often wondered why Microsoft is building tooling around Scrum and doesn’t have either of the authors of Scrum, Jeff or myself, as an adviser. We could help it avoid these mistakes and keep its tools consistent with Scrum. The right process produces the right result (from Lean). Similarly, the right implementation of the right process produces the right result.

Only build tools for things in which you have expertise, not just the experience.

Best,

Ken