Mike Cohn on transitioning to Agile Software Development at Agile Atlanta

I found out yesterday that Mike Cohn was going to be speaking at Agile Atlanta. Given that our AJUG meeting had fallen through, I pulled some schedule gymnastics in order to make the meeting. Don’t pass up a chance to hear Mike. Succeeding With Agile: A Guide To Transitioning And Improving will be his new book that fleshes out the principles of the talk he gave tonight; I scribbled down some notes below.

Agile Transition Planning

• Have goals in a transition backlog, to help you figure out how you’re doing on those goals and what you can do to assist those goals.
• Set quarterly transition goals,having those be like releases for software
• Have monthly iterations where you talk about what you can do
• Have weekly meetings talking about how you can do it
• Establish a “guiding coalition” that includes a sponsor and area managers who can help ensure success

Establish transition teams, they’re pursuing the tactical elements of some of your goals; some will be organic, some will have been formally established. Organic tends to be preferred; these will have the internal motivation necessary to get the most out of Agile.

Transition Team Members

Who to include

• Be aware of power distribution
• Know where expertise and credibility lies; passion alone does not a team member make
• Know who benefits and who loses from this
• Know what groups might have a tendency to resist this and/or may align to blockade this as an allied force; strategic inclusion can defuse this

Who to exclude

• Avoid “snipers”
• Avoid big egos
• Avoid snakes who poison relationships
• Avoid conscripts

Leading an Agile Transition

Transition team and other formal leaders must lead the transition, but not in the way they may have in the past.

Prerequisites of Self-Organization

• Container – boundaries along which people align
• Differences – enough difference to provide a vibrance
• Transforming Exchanges – interaction meaningful enough to provide value to participants

NOTE: I have had to tweak this via changes to agile team organization

Patterns of Agile Adoption

• Technical Practices First – high impact, does not scale well, partial adoption is risky
• Iterative First – not as controversial, but teams can get very complacent, scales relatively well
• Requirements First – if you’re there, OK, but meh; wait for the right project?
• Start Small – has been de facto, but less so these days, cheaper, good for those on the fence as to whether to commit, it’s slow
• All In – it’s over quickly, no organizational dissonance of having two systems at once, risky, costly, usually requires a reorganization
• Stealth Mode – no additional pressure, no one knows until you tell, no one can say no, no organizational support
• Public Display of Agility – over the top, can reduce resistance, obvious need for organizational support
• Impending Doom – can shock team out of complacency, admitting pending disaster can free team to experiment, can help overcome resistance, transition can be quick, not always an option, big change in time of trouble can increase stress

Patterns of Agile Expansion

• Split and Seed – split team up, add in newcomers
• Grow and Split – get team big then split
• Internal Coaching – develop team, give team members additional responsibilities to coach other teams

Addressing Resistance

• Sell the problem, not the solution
• Understand the types of resistance you are encountering and address them in appropriate ways