Agile Boston on Zombie Scrum Teams!

Abstract

Teams must be authorized to create team culture. They must be 100% free to invent, create, manifest and work inside their own special, unique, meaningful, largely self-determined team culture.

Ground rules set the stage for culture. All else follows. If the ground rules prevent teams from creating culture that is all theirs, then the team is dependent on outside authority and that team can never reach the hyper-productive state. The team is by definition a Zombie team ™.

Click here for details ...

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?

Project Management Institute and Massively Distributed Scrum

Non-IT Scrum is of increasing interest. Here is a Scrum run at the Project Management Institute by Dan Mesnick of Agile Boston:

MegaScrum: A Scrum Structure for Massively Distributed, non-IT, All-Volunteer Efforts

Copyright (c) 2009-2010 Dan Mezick. All Rights Reserved.

Background

Work is increasing distributed; Scrum can be adapted to fit. Some projects have these characteristics:

1. Distributed globally; it is unrealistic to assume that the people involved can get face-to-face time
2. Volunteers populate the leadership and teams
3. The work may not be related to IT or Software
4. The work has fuzzy requirements that are ever-changing and based on events
5. The work has the potential to dramatically scale up or down, meaning the total number of people involved must shift quickly to match

An object example project is the PMI Agile project, where I currently serve as Scrum Master

HICSS 2011: Call for Papers (15 June 2010 deadline)

It's time for you to get your most scintillating Agile theories together, write a kick-ass paper that could get published in the IEEE library and spend a week in beautiful Hawaii next January. Sound good?
Then get writing!

HICSS-44 CALL FOR PAPERS - submissions due 15 June 2010
January 4-7, 2011
The Grand Hyatt Kauai Resort and Spa
Kaloa, Kauai, Hawaii

HICSS-44 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield

Agile software development processes have been influenced by best practices in Japanese industry, particularly by lean product development principles implemented at companies like Honda and Toyota, and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at MIT.

This minitrack will focus on advancing the state of the art or presenting innovative ideas related to agile methods, individual practices and tools. Accepted papers will potentially enrich the body of knowledge and influence the framework of thought in the field by investigating Agile methods in a rigorous fashion.

The track is open to research papers on multiple aspects of agile methods, particularly those that bring best practices in knowledge management and lean development to scalable, distributed, and outsourced Scrum, eXtreme Programming (XP), and other agile practices.

Papers of interest include these topics:

*Research on existing or new methodologies and approaches: informal modeling techniques and practices, adapting/trimming existing methods, and new product/project planning techniques.

*Research on existing or new techniques or practices: pairing, war-rooms, test-first design, paper-based prototyping, early acceptance test driven development, exploratory testing, refactoring, or others.

*Research on special topics or tools: configuration and resource management, testing, project steering, user involvement, design for agility, virtual teams or others.

*Research on integrating ideas from other fields, e.g. interaction design, requirements engineering, cognitive science, organizational psychology, usability testing, software security, into agile processes.

*Research studies of development teams using ethnographic or social research techniques.

*Research on agile software engineering economics.

*Quantitative and qualitative studies of agile methods, practices, and tools.

*Research on agile compliance and cost benefits within CMMI, ISO 9000, and FDA certified development projects.

Papers are particularly relevant when agile processes are shown to produce quantitative and qualitative benefits across multiple implementations.

To submit papers and read more about the conference please go to the HICSS44 web page.

Jeff Sutherland
Scrum Training Institute
Boston, MA USA
jeff@scruminc.com
+1 617 606-3652

Gabrielle Benefield
Scrum Training Institute
London, UK
gbenefield@gmail.com

Nokia Test: Where did it come from?

www.slashphone.com

In 2005, Certified Scrum Trainer Bas Vodde was coaching teams at Nokia Networks in Finland and developed the first Nokia test focused on Agile practices. He had hundreds of teams and wanted a simple way to determine if each team was doing the basics.

The Nokia test is a similar to a maintenance check on your car. It looks at whether your tires have air, your tank has gas, all cylinders are firing, and makes sure there are no critical missing pieces to your car. You should perform it before you go out for a drive with your Scrum team.

It does not provide the secret sauce for hyperperforming teams. However, it is the first line of the recipe for high performance. We give this test to Scrum teams at OpenView Venture Partners and to their portfolio companies as the venture group does not expect good performance from Scrum teams without passing the Nokia test. They are also very interested in predictability of release dates which is impossible without passing grades on the test.

On 19 June 2006, announced a joint venture with Nokia Networks to form Nokia Siemens Networks. Full operations started on 1 Apr 2007 . Combined 2005 revenues were estimate at 15 billion Euro. Bas Vodde moved to China to train Nokia Siemens Networks staff on Scrum and updated the Nokia Test to include Scrum practices.

In 2007, Jeff Sutherland tuned the Nokia Test for Scrum Certification and in 2008 developed a Nokia Test scoring system. In 2009, a team question was added to the Nokia test. Click here for the lastest version.

Each person on the team takes a sheet of paper and prepares to score questions on a scale of 1-10. Teams average their score and team scores are averaged across a training class or a company to determine the Nokia test score.

Scrum training classes average a score of 4 to 5 during the first morning of the course. At the end of the course, they feel they can bring their teams up to a 6 by the end of their next Sprint using what they learned in the course.

Excel Spreadsheet for Hyperproductive Scrum Teams - very cool!

Scrum Metrics for Hyperproductive Teams: How They Fly Like Fighter Aircraft

Jeff Sutherland and Scott Downey

Agile 2010 Submission

Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in two ways. They have engines that produce velocity—alignment of the team, and team spirit. And they carefully measures aspects of performance to make slight adjustments in flight. Failing to constantly adjust the flight of the team can result in a hyperproductive crash into waterfall performance.

One hour discussion of a comprehensive, yet minimal set of team metrics used in an environment where hyperproductive teams are the norm, along with an Excel spreadsheet that can be used by any Scrum team to improve performance. Velocity, story completion by priority, work in progress, story acceptance rate by product owner, unplanned work, and trending accuracy of estimates all appear to be essential to determine the altitude, velocity, angle of attack, and attitude of a hyperproductive team. Slight adjustment of these parameters on a daily basis keeps the team on target. Half hour questions and discussion on using the Excel spreadsheet to improve team performance.

How you can download Scott Downey's extremely cool Excel Spreadsheet for your Scrum team:

Go to the Agile 2010 speaker web site:

http://agile2010.agilealliance.org/speaker.html

Click on login and sign up for a free account. You can then login and access:

http://agile2010.agilealliance.org/node/5217

Please give us a few positive comments in a review so Agile 2010 will get this submission on the agenda for the conference. You can download the spreadsheet at the link above.

Role of the Manager in Scrum

Pete Deemer, our Business Manager at the Scrum Training Institute, has written an excellent article on the role of the manager in Scrum.

---------

Like me, you probably get asked the following question quite often: "What's the role of a manager in Scrum? I'm a manager, and since I'm not mentioned in the definition of the Scrum roles, and the team is self-organizing, does that mean I'm supposed to just... disappear?" 

I recently wrote a short guide to answering this question. A couple other CST's have stumbled upon it in the last few weeks and emailed me to say they found it quite useful, and I wanted to share it with the full group as well. If you have any feedback or suggestions, I'd love to hear. You can download the guide at: Manager 2.0: The Role of the Manager in Scrum http://scrumti.com/home/stream_download/%23%3CUUID:0xb747aba0%3E-71972

Pete Deemer

Agile 2010 Abstract Posted: Hitting the Wall!

Hitting the Wall: What to Do When High Performing Scrum Overwhelms Operations

ll-at-once Scrum implementations require total commitment to change, high level management participation and aggressive removal of impediments. In July of 2009, Pegasystems (NASDAQ:PEGA) deployed 27 Scrum teams in the U.S. and India in less than two months and global continuous integration became a top priority impediment. To avoid “hitting the wall” before the first major Scrum release of their enterprise software applications, a Scrum SWAT team engineered a continuous integration environment for hundreds of software developers on two continents within a few weeks.

* Understand strategy for widespread deployment of Scrum in an enterprise
* See impact of Scrum team productivity on operations and infrastructure
* Learn how to identify top priority engineering impediments
* Be able to rapidly deploy continuous integration in a complex enterprise software environment

Create a free account at http://agile2010.agilealliance.org/speaker.html and you can download and review a draft of this paper.