Posts Tagged ‘transitioning to agile’

Four Types of Resistors When Adopting Agile

Wednesday, December 2nd, 2009

People resist changing to Scrum for many different reasons. Some may resist because they are comfortable with their current work and colleagues. It has taken years to get to their current levels in the organization, to be on this team, to work for that manager, or to know exactly how to do their jobs each day. Others may resist changing to Scrum because of a fear of the unknown. “Better the devil you know than the devil you don’t” is their mantra. Still others may resist due to a genuine dislike or distrust of the Scrum approach. They may be convinced that building complex products iteratively without significant up-front design will lead to disaster.

Just as there are many reasons why some people will resist Scrum, there are many ways someone might resist. One person may resist with well-reasoned logic and fierce arguments. Another may resist by quietly sabotaging the change effort. Still another may resist by quietly ignoring the change, working the old way as much as possible, and waiting for the next change du jour to come along and sweep Scrum away.

Each act of resistance carries with it information about how people feel about adopting Scrum. As a change agent or leader in the organization, your goal should be to understand the root cause of an individual’s resistance, learn from it, and then help the person overcome it. There are many techniques you can use for doing this. But unless the technique is carefully chosen, it is unlikely to have the desired effect. To help select the right technique, I find it useful to think about how and why someone is resisting. We can group the reasons why someone is resisting Scrum into two general categories:

  • They like the status quo.
  • They don’t like Scrum.

Reasons for resistance fall into the first category if they are actually a defense of the current approach. This type of resistance to changing to Scrum would likely result no matter what type of change was being contemplated. Reasons fall into the second category if they are arguments against the specific implications of beginning to work in an agile manner.

Categorizing how individuals resist is even simpler: Is the resistance active or passive? Active resistance occurs when someone takes a specific action intended to impede or derail the transition to Scrum. Passive resistance occurs when someone fails to take a specific action, usually after saying he will.

The figure below combines the whys and hows of resistance into four general types of resistance, each with a name descriptive of the person who resists in the way indicated by the labels on the axes.

four types of resistors

A skeptic is someone who does not agree with the principles or practices of Scrum but who only passively resists the transition. Skeptics are the ones who politely argue against Scrum, forget to attend the daily scrum a little too often, and so on. I am referring here to individuals who are truly trying to stop the transition, not people with the healthy attitude of “this sounds different from anything I’ve done before but I’m intrigued. Let’s give it a try and see if it works.”

Shown above the skeptics are the saboteurs. Like skeptics, saboteurs resist the transition more from a dislike of Scrum than support for whatever software development process exists currently. Unlike a skeptic, a saboteur provides active resistance by trying to undermine the transition effort, perhaps by continuing to write lengthy up-front design documents, and so on.

On the left side of the figure are those who resist because they like the status quo. They are comfortable with their current activities, prestige, and coworkers. In principle, these individuals may not be opposed to Scrum; they are, however, opposed to any change that puts their current situation at risk. Those who like the status quo and who actively resist changing from it are known as diehards. They often attempt to prevent the transition by rallying others to their cause.

The bottom left of the figure shows the followers, who like the status quo and resist changing from it passively. Followers are usually not enraged by the prospect of change, so they do little more than hope it passes like a fad. They need to be shown that Scrum has become the new status quo.

When introducing a complex change into a large organization, resistance will be inevitable. What isn’t inevitable is the reaction of an organization’s leaders to that resistance. In a 1969 Harvard Business Review article, Paul Lawrence describes an appropriate response to resistance.

When resistance does appear, it should not be thought of as something to be overcome. Instead, it can best be thought of as a useful red flag—a signal that something is going wrong….Therefore, when resistance appears, it is time to listen carefully to find out what the trouble is. What is needed is not a long harangue on the logics of the new recommendations but a careful exploration of the difficulty.

While its important to confront resistance, be careful not to create an atmosphere of “us” against “them.” The real goal is to create a feeling that the transition to Scrum is inevitable and that, as the Borg of Star Trek taught us, “resistance is futile.” The need to foster this atmosphere does not give you carte blanche to ignore the feelings and reactions of employees or to steamroll Scrum into an organization. Instead, to paraphrase Nigel Nicholson in a 2003 article for the Harvard Business Review, when an employee resists, an effective leader looks at the employee not as a problem to be solved but as a person to be understood.

For more help with overcoming obstacles to your agile transition, see Chapter 6 of Succeeding with Agile.

How Do You Get from Here to Agile? Iterate.

Thursday, November 19th, 2009

Historically, when an organization needed to change, it undertook a “change program.” The change was designed, had an identifiable beginning and ending, and was imposed from above. This worked well in an era when change was necessary only once every few years. But in today’s fast-paced, ever changing environment, it makes more sense to create agile organizations, ready to adapt to whatever comes their way.

But how do you manage the effort of moving from the point you are today—whether that’s just starting to adopt Scrum or fine-tuning your use of Scrum—to a place where you can readily react and respond to the vagaries of the market? By following an iterative transition process. Making small changes on a continual basis is a logical way to adopt a development process that is itself iterative. Doing so will be much more likely to result in a successful and sustainable transition. This is why I believe that the effort of adopting Scrum is best managed using Scrum itself. With its iterative nature, fixed timeboxes, and emphasis on teamwork and action, it seems best suited to manage the enormous project of becoming and then growing agile with Scrum.

Just as Scrum development projects use product backlogs, you should use an improvement backlog to track the effort of adopting Scrum in your organization. An improvement backlog lists everything that the organization could do better in its use of Scrum. If you’re just starting with Scrum, your improvement backlog will emphasize creating awareness and desire. If the transition is already well underway, your improvement backlog may contain more items around developing the ability to do Scrum well, to promote successes, or to transfer it to other groups. A small department or single-project transition may involve a single improvement backlog. But when Scrum is being adopted across a large site, department, or organization, the transition effort becomes large enough that multiple improvement backlogs are used, each of which is created by a community of individuals who are passionate about improving the organization in a particular way.

Many corporate improvement initiatives fail because plans are not made specific and actionable. Using Scrum to manage the effort of becoming agile allows you to divide the work into stories and tasks with concrete deliverables and definite end dates. At the end of every iteration, the organization will have improved in measurable and visible ways. Eventually, you will have successfully transformed the organization into one that not only is agile but also that seeks to become more agile each day.

Additional advice on using Scrum to manage your transition effort is provided in Chapter 4, “Iterating Toward Agility” of Succeeding with Agile.

There Is No End State When Transitioning to Agile

Monday, November 9th, 2009

None of the agile processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry. As Alistair Cockburn once told me, “Having a chance to change or personalize a process to fit themselves seems to be a critical success factor for a team to adopt a process. It’s the act of creation that seems to bind teams to ‘their own’ process.”

You may have a clear vision of what “doing Scrum” or “doing XP” means to you, and you may get others to buy into exactly that same vision, but where the organization ends up is likely to be somewhat different. In fact, to even refer to end states in an agile transition is incorrect; there can be no end state in a process that calls for continuous improvement.

This creates a problem for an organization that wants to transition to agile through a traditional change approach that relies on gap analysis and then on closing the identified gaps. If we cannot anticipate the end state of an agile transition, we cannot identify all of the gaps between there and the current state. So, a gap analysis–driven change approach will not work.

The closest we can come is to identify gaps between where we are now and an improved, intermediate state. After identifying these smaller gaps, though, we are still left with the problem of how to close them. It is difficult (and often impossible) to predict exactly how people will respond to the many small changes that will be needed on the way to becoming agile. Teamwork expert Christopher Avery views organizations as living systems.

We can never direct a living system, only disturb it and wait to see the response…. We can’t know all the forces shaping an organization we wish to change, so all we can do is provoke the system in some way by experimenting with a force we think might have some impact, then watch to see what happens.

So, a transition to agile cannot be a process that “articulates and defines the entire change process required to bridge the gap between ‘as is’ and ‘to be’ and creates tactical plans,” as I read in a traditional change management book recently. Creating such a plan would require leaping two impossible hurdles: first, knowing exactly where we’ll want to end up; and second, knowing exactly the steps to get there. Because we cannot overcome these impossibilities, the best we can do is adopt a “provoke and observe” approach in which we try something, see if it moves us closer to an intermediate, improved state, and if so do more of it.

These pokings and proddings of the organization are not random. They are carefully selected based on experience, wisdom, and intuition to drive a successful transition to agile.

For more information on this topic, see Succeeding with Agile: Software Development using Scrum.

Patterns of Agile Adoption

Wednesday, January 16th, 2008

There are many ways to transition to an agile process. Choosing the approach that is most likely to work best for your organization can be critical to a smooth transition.  In Mike Cohn’s article, Patterns of Agile Adoption, he has identified six core patterns that teams use to initiate the transition to agile.

Salesforce.com’s Three-Month Transition to Agile

Thursday, October 11th, 2007

Mountain Goat Software client Salesforce.com successfully completed one of the quickest, large-scale, big-bang agile transitions ever, involving over 200 developers. At the Agile 2007 conference they shared this presentation on how they did it.