Mike Cohn
gave a talk at Agile 2007 about how to succeed in Agile based on his experiences with different clients transitioning and successfully transforming their organization.Mike starts out by addressing why organizational change is hard:
1. It’s not top down where a strong leader sets a vision and people follow it, and it is not bottom up where team start and others follow until you run into groups that are powerful enough to squelch transition.
2. Best practices are tempting, but once we identify something as best, we stop changing. We have to keep inspecting and adapting otherwise we are not agile.
3. The transition has to also go with a transition in the development process
4. We cannot predict how the organization is going to respond. We want to effect the organizational change in an incremental manner.
Mike describes how if we break things up into small pieces, work on the smaller more manageable pieces and then try to put them back together we do not necessarily get the whole picture. We need to think of organization as complex adaptive system. We need to look at success as achieving a good fit with the environment instead of as closing the gap with the desired state. We have to acknowledge that agents are closing local goals and closing local gaps. They are thinking about their own job security and their own vacation schedule. It is ok to set vision, but each agent is pursuing their own local goals and they are taking local actions and they all interact.Mike next contrasts the traditional model of change vs. the complex adaptive model for change.
1. Traditionally, behavior is controllable and predictable. In the complex model we cannot control behavior.
2. Traditionally, we can establish directions. . In the complex model direction is established by the moving groups.
3. Traditionally there is clear cause and effect. In the complex model, there is a ripple effect.
4. Traditionally, relationships are directive. In the complex model, relationships are empowering and can go in both directions.
5. Traditionally, focus is on efficiency. In the complex model we are more interested in responding to change.
6. Traditionally, decisions are based on fact and data. In the complex model, decisions are based on patterns and tensions between groups.
7. Traditionally, leaders are the experts. In the complex model, everybody can help lead. Leaders are there to facilitate and support.
Then Mike moves on to describe a framework for transition. He compares transition to an agile project. On a project we learn that we cannot perfectly predict things. We cannot predict requirements, we cannot predict schedules, and we cannot break things into WBS. Instead we spec just enough to get moving and then inspect and adapt and respond. We need to do the same on our transition process. Probe the organization and push it in some way, and then inspect and adapt. He recommends changing a typical Scrum product development process into a transition process. Make the product backlog a transition backlog. List of things we need to do to transition. Plan and select 3 to 4 transition goals for the quarter. Set monthly milestones and have monthly iterations and see how we are doing. . Encourage people to meet weekly to coordinate transition.Mike recommends establishing a guiding coalition which consists of a sponsor who is someone high up executive chain who can make things happen and area leaders, team leads, and department managers that can help identify things that are wrong in organization.
He also recommends establishing a transition team. On a small transition this can be same as development team. In a large organization, it will be members from different groups. They can start out and then recruit more people. We have to always think about who stands to gain or lose from transition. Are their groups that are going to organize against this? Make sure you have influential leaders on the team. Think who should not be on team like people with big egos or people who do not know where they are week. Avoid people who try to sabotage things and be careful with reluctant participants. It is better to have people committed and involved.
Mike then cover the role of leaders in this process. The can no longer simple say just do as I say. They have to lead through example, question and focus. They have to let the team figure things out and decide on their own to move to things like pair programming or test driven development.
Mike then describes the CDE model for self organization to happen:
1. Container: The team has to be within a container (project, room, city, role, nationality). Something that brings the team together and have some commonality.
2. Differences: If everybody was the same, there won’t be any self organization. We need to bring in different skills. Developers, testers, domain knowledge, etc.
3. Transforming exchanges: interact and exchange information and knowledge
Part of the role for leadership is making self organization happen in the right way. Look at how things are working in the organization and change things. Change container, differences, and exchanges: change team size, make them collocated, add new members, change responsibility. Differences: cross functional, combine junior people with senior people, and change how team makes decisions. Exchanges: Bring in outside consultant, put up burn down charts, change reporting structure,
Next Mike list 8 patterns of agile adoption:
1. Technical practices 1st approach. Start with XP practices, pair programming, unit testing, TDD, Continuous integration. If you can pull this off you can be good very quickly. Disadvantage is that a lot are dependent on each other. For example, you cannot do refactoring without unit testing. There will be resistance to some practices and change will slow team down in the beginning. This pattern is useful when the most pressing issues are technical ones, the transition is not a large transition, the team has good solid technical skills, and there is a desperate need to improve.
2. Iterative 1st approach. Start with Scrum. Let’s see what we can produce in the next iteration. It’s easy to start, but the team might not end up picking up the technical parts. It works well with large groups or when you are stuck on a stalled project.
3. Requirements 1st approach. If we start out with agile requirements, it then makes it hard to avoid agile later. We need to do this in the beginning of the project and we need to have an idea of what we want to build. So we have to wait for the right time for this approach and starting the project will take longer.
4. Start small. Start with a couple of teams. Learns from their mistakes. This minimizes costs and almost guarantees success since usually the best people are put on the team. However, we need to be careful with our conclusions, it might take a lot of time, and agile teams will need to work with non agile teams. This is useful when there is a reluctance to commit fully to agile, the risk of failing an at once transition outweigh the advantages, and you can afford the time it takes.
5. All in. It’s over quickly, it can reduce resistance, and everybody is using agile process. However, it’s risky, it’s costly, and it will likely require a reorganization. It’s useful when you want to send a clear message, time is critical, and your team is not too big or too small.
6. Stealth mode: There’s no additional pressure. No one knows about it until you tell them about it. However, you won’t have organizational support, skeptics will only hear about success and not witness it. It is useful when you want to experiment, you expect strong resistance, and you don’t have organizational support
7. Public display of agility. Everyone knows you are doing it, it establishes a vision to work towards, makes a firm statement that you are committed to transitioning. However, resistance will come out all at once. It is useful when you are committed to achieving it and confident in the approach and want to face the resistance all at once.
8. Impending doom. Competitors are going to take you out of the market unless you change. You have to be sincere. It can be quick. It can overcome a lot of resistance. It can help the team shape up. However, a big change in a time of trouble can be stressful. This is useful when a project is failing unless there is dramatic action
Next Mike covers 3 expansion patterns:
1. Split and seed: Take members of a team and divide them up and add new members to make 2 teams. This however takes one good team and split into 2 regular teams until they become good at a later date.
2. Grow and split: Good if in an expanding project. Take initial group and grow it until it is a little too big and then split it. We always have good teams however it will take long.
3. Internal coaching: team members have a secondary role to be a coach for another team. They have a small set of additional responsibility to do for the other team.
Finally, Mike covers some early transition issues:
1. Overcome resistance: Focus on the problem and not just solution. When selling TDD, asks them how could we have prevented this bug from showing up. Communicate why we are doing something. Have development get in touch with customers. Let development see the type of complaints we are getting. Make sure everybody will have a role. Focus on benefits.
When experiencing resistance need to figure out which group is it coming from and what can you do to work with this group. Mike describes the disposition to change continuum based on an article in the Harvard Business Review as:
- 1. Conservers: Do not like change. Changes have to support the status quo. Very cautious.
- 2. Originators: undisciplined and unorganized. Constantly challenging assumptions. Not concerned with policy. Constantly changing things. Maybe too quickly
- 3. Pragmatists: willing to talk about it. Need to see proof and result.
Mike then describes different tools to use based on the situation. There are tools like:
- 1. Leadership tools: Charisma, Salesmanship, role modeling,
- 2. Culture tools: Rituals, democracy, tradition
- 3. Power tools: Role definition, threats, coercion
- 4. Management tools: Metrics, incentives, standards
2. Have a customer. The role of the customer is different from a traditional model. Try to get someone how is committed throughout the process.
3. Get change agents involved. Get a transition team established. Have them identify other people and pulling them into team. Look for people who think differently than you. Get people with unusual backgrounds.
4. Follow a guide. Get someone who has experienced it.
Mike wraps things up by advising that the use of consultants is helpful in diagnosis, and capabilities assessments, but strategy and implementation of the change has to come from the company. Don’t get overly reliant on consultants.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-Transitioning-Mike-Cohn
