This has, of course, coincided with the growth in popularity of the agile development methodologies, including Scrum. These approaches have become popular because, among other benefits, they help companies deliver products more quickly.

Why I’ve been thinking about this lately is I’ve begun to wonder if we’re nearing the end of the era in which time is a competitive advantage in project management. It’s quite possible: Other sources of competitive advantage have gone away.

Quality, for example, used to be a one of the strongest differentiators among companies. Thirty years ago, quality varied tremendously among carmakers. Today, a high quality car is assumed. Quality–at least in most manufactured goods–has largely gone away as a source of competitive advantage.

Price has long been a source of competitive advantage. But some authors have even argued that as more products and services are offered for free, price is going away as a competitive advantage.

Innovation has become a fertile area in which companies seek competitive advantage today. This has served Apple well over the past decade. I don’t think innovativeness will be going away soon as a source of competitive advantage. But I do wonder whether time is running out on time as a competitive advantage. If project management using agile and other innovations lead us to a world where all companies can deliver new products and services equally quickly, companies will need to find newer ways to differentiate themselves.
Let me know what you think.

Layfayette, CO November 29, 2010 — ScrumMaster and agile expert Mike Cohn has announced his new agile and scrum training class schedule in Europe and the US for January through March 2011.

As in years past, Mountain Goat Software is once again bringing Scrum expert Mike Cohn’s agile software development training knowledge and expertise to Norway, and England as well as the Silicon Valley, Irvine, San Diego and Dallas in the United States in 2011.

Mike Cohn personally teaches agile project management classes for both new and current Agile teams and team members and class participants benefit by learning new ways of working and practical skills that can be immediately applied. All classes include an appropriate mix of lecture, small-group discussion and hands-on exercises. As a Registered Education Provider through the PMI, attendees earn Category 3 PDUs.

According to Gabrielle Benefield, Former Director of Agile Development, Yahoo!, “Mike’s classes at Yahoo! have been incredibly useful. I recommend him to anyone who is serious about implementing Agile in their organization. ”

A veteran of agile projects since 1995, Mike Cohn teaches how Agile software development training teaches teams how to emphasize teamwork, produce frequent deliveries of working software, develop close customer collaboration, and achieve the ability to respond quickly to change. For additional information and to register, visit the Mountain Goat Software website and learn more about the certified scrum and agile training available.

About Mountain Goat Software and Mike Cohn

Mountain Goat Software is an Agile Methodology Training and Project Management Consulting Company founded in 1993. Owner, lead trainer and author of three very popular books on agile, Mike Cohn has also written numerous articles for magazines, journals, and websites. He has a blog on succeeding with Agile and is a frequent participant in agile and scrum discussion groups.

Contact:
Mike Cohn, CEO and Lead Trainer
Mountain Goat Software
888-61-AGILE
mike@mountaingoatsoftware.com

http://www.MountainGoatSoftware.com

###
Layfayette, CO November 29, 2010 — ScrumMaster and agile expert Mike Cohn has announced his new agile and scrum training class schedule in Europe and the US for January through March 2011.

As in years past, Mountain Goat Software is once again bringing Scrum expert Mike Cohn’s agile software development training knowledge and expertise to Norway, and England as well as the Silicon Valley, Irvine, San Diego and Dallas in the United States in 2011.

Mike Cohn personally teaches classes for both new and current Agile teams and team members and class participants benefit by learning new ways of working and practical skills that can be immediately applied. All classes include an appropriate mix of lecture, small-group discussion and hands-on exercises. As a Registered Education Provider through the PMI, attendees earn Category 3 PDUs.

According to Gabrielle Benefield, Former Director of Agile Development, Yahoo!, “Mike’s classes at Yahoo! have been incredibly useful. I recommend him to anyone who is serious about implementing Agile in their organization. ”

A veteran of agile projects since 1995, Mike Cohn teaches how Agile software development training teaches teams how to emphasize teamwork, produce frequent deliveries of working software, develop close customer collaboration, and achieve the ability to respond quickly to change. For additional information and to register, visit the Mountain Goat Software website and learn more about certified scrum and agile training available.

About Mountain Goat Software and Mike Cohn

Mountain Goat Software is an Agile methodology training and project management consulting company founded in 1995. Owner, lead trainer and author of three well read books on Agile, Mike Cohn has also written numerous articles for magazines, journals, and websites. He has a popular blog on succeeding with Agile and is a frequent participant in agile and scrum discussion groups.

Contact:

Mike Cohn, CEO and Lead Trainer
Mountain Goat Software
888-61-AGILE
Mike@MountainGoatSoftware.com
http://www.MountainGoatSoftware.com

###

I was at a conference when I saw Derek walking toward me. I had first met him a year earlier when I taught a class at his company. I had been back a handful of times, and always enjoyed talking with him. We hadn’t talked in three months and I thought this would be a good chance to catch up. As we said hello, I could tell something was really bothering him, so we sat down to talk. Derek told me during his team’s sprint review the week before, they asked him to resign as their ScrumMaster and leave the team. He did and was looking around within his company to find another Scrum team to join.

Although rare, Derek’s situation is not unheard of. The question of whether the team has the authority to remove a member is a common topic. Commonly referred to as “voting someone off the island,” removing a team member is not an action to be considered lightly. Every effort should be made to address problems that might lead some or all project team members to feel they will be better off without a particular member.

An agile or Scrum team alone should not have the right to remove someone from the team. As I detailed in Chapter 12 of Succeeding with Agile, self-organization does not occur in a vacuum. The right preconditions must be in place for self-organization to occur. Individuals then self-organize within boundaries established by the organization. This is referred to as the CDE model, which says that for self-organization to occur there must be a container that bounds the individuals, some differences among them, and transforming exchanges.

Chapter 12 in Succeeding with Agile also makes the point that leaders within the organization exert influence on the self-organizing team by adjusting its containers, differences, and exchanges. For example, over time and through attrition a team might become too homogeneous. An astute scrum product owner, functional manager, or even ScrumMaster might counter by adding two new team members with radically different backgrounds, skills, decision-making styles, or so on. Doesn’t it seem possible—likely even, in this example—that a team might have a knee-jerk reaction and vote the new, nonconforming individuals off the team, negating the work of the leader who deliberately added them? Ultimate authority for team composition, therefore, must reside with the leadership of the organization. Those leaders should listen, of course, when team members say they think they’d be more productive without a member. But, team members should not be allowed on their own to remove someone from the team.

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.

Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In “The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.”

An agile or Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. Management’s job is to come up with appropriate challenges and remove impediments to self-organization. That being said, the fewer constraints or controls put on a team, the better. If leaders overly constrain how an agile team solves the challenge given to it, self-organization will not occur. The team will shut down; because it has already been told so much about the challenge and how to solve it, it will wait to hear the rest. So how does an agile leader achieve the subtle balance between command and influence?

Suppose you are a ScrumMaster for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the ScrumMaster for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve. You consider having a private conversation with Jeff, but that is unlikely to change much. You contemplate stepping in and overruling some decisions he makes, but if you do it once the team will expect you to continue to do so, which won’t be good.

Then you begin thinking about the agile principles of subtle control and influence. Perhaps you decide to change the team’s dynamics by asking management to add someone new to the agile team, someone who is likely to stand up to Jeff. Or maybe you suggest to the enterprise architecture team that someone from its group attend key meetings—someone with the experience and background to challenge Jeff. No matter the specific problem, if you see that the team has self-organized in a way that impedes it, it is your responsibility to find a way to agitate, stir up, or otherwise disturb the status quo, so that the team adjusts, hopefully reorganizing in a more productive way.

There is more to leading a self-organizing team than buying pizza and getting out of the way. Leaders influence teams in subtle and indirect ways. It is impossible for a leader to accurately predict how a team will respond to a change, whether that change is a different team composition, new standards of performance, a vicarious selection system, or so on. Leaders do not have all the answers. What they do have is the ability to agitate teams (and the organization itself) toward becoming more agile.

For more details on how leaders can help teams and their organizations grow more agile, see Chapter 12 of Succeeding with Agile.

The Role of Leaders on a Self-Organizing Team by Mike Cohn is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.
Based on a work at blog.mountaingoatsoftware.com.

This is wrong, however. On an agile project—as well as in many other cases—there is no single, wringable neck. To say there is a way of releasing the rest of the team from responsibility. And this is clearly wrong.

From a manager’s perspective it can be nice to always be able to point to one person and say, “That’s who I’ll blame if things go wrong.” Howerver in agile project management the “one throat to choke” argument is false. Historically, there may be one person who takes the blame for things when they go wrong, but that doesn’t mean that person was responsible for the failure.

Take the case of a sports team. At the start of a new season, who on a sports team do we say we’ll hold responsible for winning the championship? The coach? The owner? The star player? Teams that win championships find a way to win games, no matter the circumstances. If the game plan isn’t working, the coach and players adapt. If the star player is having a bad day, someone else steps up. The whole team feels responsible for winning somehow, some way. If the team loses, it may be tempting to blame one person or another, but the team knows that each one of them is accountable for the loss. It’s never just one person’s fault. In reality, there is no single, wringable neck.

Consider a nonsports analogy. If both parents were involved in raising a child (and assuming one of them isn’t abusive or obviously negligent), which parent is the one throat to choke if a child grows up to be a convicted felon? There is a reason we call it a parental unit. Raising a child is a team effort.

The only way to ever create an environment of shared ownership and responsibility is to let go of the notion of having one throat to choke. That doesn’t mean no one is responsible. That means that on a successful team, the team members must do their part, or even go beyond a perceived role, to ensure that the team reaches its goals.

The project was to be delivered into multiple call centers with more than 300 nurses on the phones. It was to replace a quirky but familiar system that the company was rapidly outgrowing. The nurses’ expectations of what the new system would deliver were sky high. In monthly sprint reviews with the nurses, I was routinely shocked by what they’d come to expect, some of which wasn’t even technically feasible.

With about three months left on the year-long project, I realized my focus had to change. From then on, I spent almost all of my time on expectations management. I met with nurses in each of the call centers and described exactly what would and would not be in the delivered system. I toned down their expectations about the system’s impact on world peace, global warming, and personal weight loss. Without this effort, the product would have been perceived as a failure.

Since that project, I have been acutely aware of the importance of expectations management to the overall success of any project. Setting and managing expectations is perhaps even more important at the start of a major shift such as adopting an agile project management approach like Scrum. In initiating a transition to Scrum, I find it helpful to set and manage expectations about four things:

• How quickly teams will improve
• How long it will take to gain additional predictability from the team’s new way of working
• How there will almost always come a time when turning back looks easier than sticking with it
• The level of involvement in the transition that will be necessary from various stakeholders and organization leaders

By properly setting expectations you can avoid the problem of having an otherwise successful transition or project sunk by unrealistic expectations.

More details about setting and managing expectations can be found in Chapter 5 of Succeeding with Agile.

Finding the right project was the most critical and challenging task. We needed a meaty project that people would not dismiss as being a special case, yet we did not want a project to fill every possible challenge—too much was riding on its success.

Not every project is equally suited to be your first. The ideal pilot project sits at the confluence of project size, project duration, project importance, and the engagement of the business sponsor, as shown in the figure below. You may find it impossible to identify the “perfect” pilot project. That’s OK. Consider the projects you do have and make appropriate trade-offs between the four factors presented in the figure shown below. It is far better to pick a project that is close enough and get started than it is to delay six or more months waiting for the perfect pilot to present itself.

Duration.
If you select a project that is too short, skeptics will claim that Scrum works only on short projects. At the same time, if you select a project that is too long, you risk not being able to claim success until the project is over. Many traditionally managed projects claim to be on track 9 months in to a 12-month schedule, yet in the end are over budget and late, so a Scrum project proclaiming the same may not be very convincing.

What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits to them and to the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects.

Size.
Select a project that can be started with one team whose members are all collocated, if at all possible. Start with one team, even if the pilot project will grow to include more teams. Try to select a pilot project that will not grow to more than five or so teams, even if such projects will be common in your organization. Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn’t have time to grow from one team to more than five anyway if you also looking for a project that can be completed in three or four months.

Importance.
It can be tempting to select a low-importance, low-risk project. If things go badly, not much will be lost. And people may not even notice a failure on a low-importance project. Don’t give in to this temptation. Instead, pick an important project. An unimportant project will not get the necessary attention from the rest of the organization. Additionally, some of the things required of a team transitioning to Scrum are difficult; if the project isn’t important, people may not do all that is required of them. Early agilist and inventor of the Adaptive Software Development process Jim Highsmith gave advice about this in Agile Software Development Ecosystems.

Don’t start with an initial ‘learning project’ that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you.

Business sponsor engagement.
Adopting Scrum requires changes on the business side of the development equation, not just the technical side. Having someone on the business side who has the time and inclination to work with the team is critical. An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals. Similarly, there is no one more useful in promoting the success of the project afterward than a sponsor who got what was expected. One sponsor commenting to another that a recent project tried Scrum and delivered more than past projects did will do wonders in getting other sponsors to ask their teams to also try the new approach.

And Finally: People.
I’m not forgetting the importance of the people involved to the success of a pilot. The people involved are, of course, the most important factor in the success of any project. The advice provided in this blog post assumes that you have already chosen the appropriate team and are now seeking to match them to the best possible pilot. Additional advice on selecting the individuals who will form pilot teams is given in the “Selecting a Pilot Team” in Chapter 5, “Your First Projects” of Succeeding with Agile.