Avoiding Pitfalls in Your Agile Transformation

Here is an eight point checklist that will help you save time and avoid common pitfalls.

• Be Type Aware
• One’s a Maverick, Two’s a Team
• Get Executive Cover
• Expect the Change Curve
• Lead with Pain
• Tool Up
• Create visibility
• Don’t Dictate – Facilitate

Be Type Aware. The Myers-Briggs Type Indicator (MBTI™) is used to help individuals understand their preferred ways of working, and to help teams appreciate diverse viewpoints. It lets people discover their most comfortable ways of working. For example, some people refresh your energy by being with other people, and others prefer to read a book alone. Some learn about their environment through models, and some with data. Some decide issues based on impact to people, and some prefer more detached logic. And some prefer spontaneous adaptation versus well laid out plans. Unnecessary friction can develop on the team without appreciation that people may differ not just in technical skill, but also in temperament and working style. This is especially true during the stress of process change. Educating the team in the different styles of workers up front and respecting the differences will side step this pitfall. MBTI™ has served many teams well, but other similar tools are available.

One’s a Maverick, Two is a Team. An agile evangelist on the team can’t work alone. The can be viewed as an outlier. When two people embrace a targeted practice on your team, they support each other, but also publicly show unity of support for the practice. Getting at least two champions on the team for a new change gets people to herald it’s adoption and the reverse is true. A change with only one champion often never comes to fruition.

Get Executive Cover. Change feels threatening to people who are talented in their previous ways of working. They are vested in skills they have developed, and their success as led them to leadership positions. Show them that the addition of agile practices can add fresh tools to their pallet of skills. And most importantly, get buy-in from upper management to support the change initiative.

Expect the Change Curve. Agile will make you more productive. Some organizations may be tempted to mark teams Agile, then reduce their staff due to expected increases in efficiency. This is a trap at the beginning. The Process Change Model by Virgina Satir [1] says that we will first encounter resistance and less productive chaos. Benefits will come, but the cost of change will counter balance the benefits while you are getting started. You have to invest before you see the gain.

Lead with Pain. Instead of announcing the team will be doing a new practice, star by discussion the pain points that make the practices useful. For example, say “We seem to lose a lot when people leave the team”. This may highlight the need for pair programming with rotating combinations. “Sometimes people don’t like what we’ve built, even after careful specification”. The practice of using feedback from iteration demos will become attractive. Showing the problem and need, then bridging to selected approaches eases the team’s changes.

Tool Up. Spreadsheets and index cards are useful for learning agile concepts and are easy to work with, but using a tool designed for agile project management like VersionOne, RallyDev, or AgileZen helps guide new teams through the process. Moreover, it shows skeptics that there is a long history of industry investment. Introduction of tools specifically designed for an agile process is usually a pivotal moment of change.

Create Visibility: Agile shines when the whole team can understand the flow of work, and pitch in to help or identify problems. Your selected agile project management tool can help, and physical artifacts can supplement these. You’ve succeeded if team members know not just the status of their work, but have an idea of the workflow of the team as well. Artifacts for this can include Scrum’s burn down chart, the taskboard or Kanban board, build and test success lights for continuous integration

Don’t dictate – Facilitate. There are variety of good assessment surveys for your teams retrospectives or lessons learned, such as the Shodan Adherence Survey [2], the Agile Evaluation Framework, [3], Comparative Agility™ Assessment [4], and the Sidky Agile Measurement Index (SAMI) [5], IBM Rational Self Check for Software Teams [6], and Dean Leffingwell’s Agile Process Metrics [7]. They rate questions numerically to view the team’s deployment level of given practices. This gives people a head start on a solid combination of practices.

But counter intuitively, there is also a niche for placing the work of authoring questions, targeting towards measuring their progress with “being” agile on the team members. This engages another section of their brain. They can bring their unique perspective on observed problems, and key practices into the instrument. Numerical assessments of teams can rotate between a repeated standard list of questions, one of several alternate sets for variety, non numeric retrospective techniques as described by Derby and Larsen in “Agile Retrospectives” [8]. Try also adding a session for an iteration’s retrospective where the team constructs six questions. The act of choosing the top 6 and wording the questions can be a key learning moment. The coach can cue the team by suggesting they consider practices in the following key areas: requirements analysis, workflow management, building quality, and process optimization. Within that framework, people should engage their experience to choose fresh questions. The exercise of considering these can be as valuable as the questions and data themselves.

This approach gives you the best benefits of each technique. You get historical trend data, variety to explore fresh questions on alternate iterations, non numeric methods, expert thought using pre-crafted questions and best of all, team buy in and enthusiasm for the questions they have developed. Learning from the experts is good, but sparking the learner’s analysis of what they would ask is equally powerful.

The coach’s role is to help the team create their questions. The coach can guide the team in considering some key areas, such as what practices they feel are key for quality, or what practices they feel are key for requirements. The coach can also warn the team of known pitfalls in terms of which wordings or practices may not work. But the coach also needs to be open minded. The goal is not to lead the team to a particular answer, but to enable the team’s creation of a question set that works for them in use, and teaches them in the process of its creation.

This example shows questions that were developed not by a consultant, but by a team beginning their agile journey. Having them write the questions serves as a great way for coaches to glean the team understands the core principles. Longer consultant generated surveys are still fine, but these team generated ones give you a view of what’s inside the mind of the team.

The questions given in the table are just examples of what one beginning team did to fill in the empty spreadsheet. The value is in the emptiness.

References

[1] Virginia Satir. Satir Change Model. http://www.satirworkshops.com/files/satirchangemodel.pdf

[2] William Krebs. “Turning the Knobs: A Coaching Pattern for XP through Agile Metrics”. Springer, 2002

[3] Laurie Williams, William Krebs, Lucas Layman, and Annie I. Antón, "Toward a Framework for Evaluating Extreme Programming," Proceedings of the 8th International Conference on Empirical Assessment in Software Engineering (EASE '04), Edinburgh, Scotland, May 24-25, 2004, pp. 11-20.

[4] Mike Cohn. “Succeeding with Agile”. Addison-Wesley, 2009. Also online at comparitiveagility.com by Mike Cohn and Kenny Rubin.

[5] Ahmed Sidky and James Arthur. “A Disciplined Approach to Adopting Agile Practices: The Agile Adoption Framework”. Agile journal, June 2007. Also see “Becoming Agile” by Greg Smith and Ahmed Sidky. Manning 2009

[6] Per Kroll, William Krebs. “Introducing IBM Rational Self Check for Software Teams”. developerWorks ®

[7] Dean Leffingwell. “Scaling Software Agility” Addisson-Wesley 2007.

[8] Ester Derby and Diana Larsen. “Agile Retrospectives”. The Pragmatic Programmers, 2006.

MBTI is a trademark of the Myers-Briggs Type Indicator Trust

IBM is a trademark of the IBM Corporation.

developerWorks is a Trademark of the IBM Corporation.

Learn more: see VersionOne.com, Rallydev.com, and AgileZen.com for more details the tools mentioned.

About the Author

“AgileBill” Krebs has worked as a developer and agile coach at five IBM labs since 1983. Since 2001, he's used and taught Agile methods worldwide, teaching over 50 classes to 1,000 engineers and managers. He's presented at agile conferences, IBM Research, the IBM Academy of Technology conference on Agile. He holds two certifications in Scrum, one in MBTI is completing a certificate in virtual worlds in 2010. Currently he teaches with Davisbase LLC, and is the founder of Agile Dimensions LLC where he specializes in efficiencies using immersive virtual environments. Bill is also a member of the Scrum and Agile Alliances in addition to his local Agile RTP user group. Find Bill on LinkedIn, agiledimensions.com, or the worldwide Agile 3d (www.meetup.com/agile3d) user group.