Scrum Log Jeff Sutherland

Scrum is an Agile development framework that Jeff Sutherland invented at Easel Corporation in 1993. Jeff worked with Ken Schwaber to formalize Scrum at OOPSLA'95. Together, they extended and enhanced Scrum at many software companies and helped write the Agile Manifesto.

Sunday, March 07, 2010

Roots of Scrum: Takeuchi and Self-Organizing Teams

The first Scrum team was created directly from a paper which is required reading for any Scrum practitioner. It explains how to set up self-organizing teams and clearly outlines management's role in the process.

Takeuchi and Nonaka. The New New Product Development Game. Harvard Business Review, 1986

A longer paper from a book which is out of print goes into more depth. Some may find this easier reading.

Ken-ichi Imai, Ikujiro Nonaka, and Hirotaka Takeuchi. Managing the New Product Development Process: How Japanese Companies Learn and Unlearn.

Also see Takeuchi and Nonaka's books. Their latest books do in-depth analyses of Toyota.

Takeuchi and Nonaka clearly explain the fundamental concepts so often missed by management and teams new to Scrum. The discussion of self-organizing teams is a good example:

A new product development team, consisting of members with diverse backgrounds and temperaments is hand picked by top management and is given a free hand to create something new. Given unconditional backing from the top, the team begins to operate like a corporate entrepreneur and engage in strategic initiatives that go beyond the current corporate domain. Members of this team often risk their reputation and sometimes their career to carry out their role as change agents for the organization at large.

Within the context of evolutionary theory, such a group is said to possess a self-reproductive capability. Several evolutionary theorists use the word "self-organization" to refer to a group capable of creating its own dynamic orderliness. A recent study by Burgelman found that a new venture group within a diversified firm in the United States takes on a self-organizing character. Another study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records than others.

The creation and, more importantly, the propagation of this kind of self-organizing product development team within Japanese companies represents a rare opportunity for the organization at large to break away from the built-in rigidity and hierarchy of day-to-day operations. It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. The effort collapses somewhere in the hierarchy. A new product development team is better suited to serve as a mote for corporate change because of its visibility ("we've been hand picked"), its legitimate power ("we have the unconditional support from the top to create something new"), and its sense of mission ("we're working to solve a crisis situtation").

An alternative view of a parallel approach is outlined in:

Chet Richards. Certain to Win. XLibris Corp, 2004.

Richards outlines the strategy of fighter pilot John Boyd. He uses German concepts to illustrate key ideas.

* Enheit -mutual trust, unity, and cohesion
* Fingerspitzengefuhl - intuitive feel, especially for complex and potentially chaotic situations
* Auftragstaktik - mission, generally considered a contract between superior and subordinate
* Schwerpunkt - Any concept that provides focus and direction to the operation

He takes these concepts down to second order interactions. Trust builds by training in the field and by mission driven challenges that a self-organization team accepts or does not accept. It they accept, they can be counted on to do it or die in whatever way they see fit without intervention by the superior. This level of trust depends on the team trusting the rightness of their leader. If superiors do anything to disrupt the team, trust breaks immediately.

With trust based on real unity and cohesion, Boyd's Observe, Orient, Decide, Act feedback loop goes into an implicit state where there is Observe, Orient, and Decisions becomes implicit. The team goes into motion before the leader can give a command. Like in martial arts the Sensei is moving before he even sees the motion of the attacher using a sixtth sense. This is the kind of trust a Dream Team has. You know it when you see it and how come so few software teams have that level of trust?



Blogger The Shiny Monkey said...

Thank you for this post. Reading it in preparation for Tobias Mayer's course in SF this month.

One thing. "Like in martial arts the Sensei is moving before he even sees the motion of the attacher using a sixtth sense."

As a former teacher of martial arts, I felt it absolutely critical that students knew that anything I could do, they could do. And, if they were good students, there would be many things they would learn to do much better than I could.

Most *sensei* do not teach this way, which is why I opted for a truly agile martial art in the end.

A major part of the reason I changed the way I practice law is due to the "agility" created once I took an objective look at what was taught in traditional styles.

Everyone has this "sixth sense," the question is whether the leader chooses to nurture it every practice,--or whether the student is to told "wait until you grow up" (e.g. get a black belt) in order to have it made manifest.

12:39 AM  
Blogger jmeydam said...

Hi Jeff

Some time ago I've re-read the Takeuchi and Nonaka paper. I was struck by the fact that all the teams were given broad or even vague missions and were trusted to do the right thing.

This is in stark contrast to the style of Scrum that you seem to favor these days. You tend to emphasize that teams should only start work on READY backlog items, i.e. items that leave very little room for discovery (apart from discovery at the implementation level).

While I understand that this way of working leads to a high degree of /efficiency/, don't you see a possibility for teams to be more /effective/ if they engage directly with the users and master the subject domain? Wouldn't that be closer to the teams Takeuchi and Nonaka describe?

By the way, I take great interest in everything you publish or say in public on "the first Scrum" at Easel, as I am sure do others. How about writing a book on this topic?

2:05 PM  
Blogger Jeff Sutherland said...

I'm emphasizing READY and DONE now because that is the major source of disfunction on current Scrum teams. We are also emphasizing that the entire team needs to devote 5-15% of their total time to helping the Product Owner get the backlog ready for future sprints.

In Takeuchi's teams the cross functional team often had to figure out what the product should be. Emergent leadership often occurred to enable this. The best Product Owners I know work with the teams this way.

Remember Tacheuchi looks at their teams and it reminded them of the Scrum formation in Rugby. This is intense, focused, and very high energy. In this state, the team works with the product only to get the backlog clear and compelling so they can knock down a great product at high speed.

For the precious few teams that are hyperproductive, it is all about entering into a flow state. People want to watch Tiger Woods hit the ball again so they can experience vicariously the moment when Tiger knows the ball is going in the cup when he is still swinging the club. This flow state merges what people love with the work they do and generates a powerful ecstasy. When the entire team goes into flow it is even more transformative than the individual state.

The Apple management team conveyed some of this flow when they did the iPad launch video. It brought down the internet in Sweden at the time. I think this is the kind of thing you are looking for but it only comes after people can get working software at the end of a Sprint on a regular basis. Before that the impediments disrupt flow constantly.

4:37 PM  
Blogger jmeydam said...

Hi Jeff,

Thanks a lot for taking the time to respond in detail. You have helped me to understand better what you aim for, and perhaps I am beginning to see the light. :-)

By the way, in 2008 I came all the way from Switzerland to Aarhus to take your ScrumMaster class. A few months ago you gave a class in Pfäffikon in Switzerland, didn't you? That's a ten minutes drive from where I work. Maybe that's a sign of how far Scrum has spread.


2:35 PM  

Post a Comment

<< Home