Agile Transformation vs. Agile Adoption

Agile methods are now popular enough that the Project Management Institute has officially recognized them in a number of ways including setting up an agile project management community for PMI members.  This is a good sign, and I re-joined the PMI as a result.  However, there is still a big gap between “doing” agile and “Going Agile”, between adopting agile methods for project management and transforming your organization to become agile in all aspects of its work.  Most people are “doing” and “adopting” agile, not doing the deep transformation.

For some years now, the premise I have been working on is that agile methods are actually all about learning.  They aren’t about product delivery.  Rather, product (or service) delivery is the context for learning.  What does this matter?

Let’s imagine two similar organizations, Abacus and Brightstart.  Both organizations want to improve the way they are working.  In fact, they both see many similar opportunities in terms of efficiency gains, productivity gains, and improvements in customer satisfaction and employee morale.  Abacus is headed up by Alex who is a visionary leader whereas Brightstart is headed up by Brit who is a hard-nosed bottom-line kinda person.  Now just to make this interesting, let’s pretend that Alex doesn’t understand Agile and just wants to use an agile method as a way to improve the delivery of projects at Abacus.  Brit, on the other hand, has some trusted advisors who have insisted that agile be treated as a fundamental transformation in the way Brightstart does business.  What happens?

Abacus

Alex gets a staff member to attend some Scrum training and launch an agile pilot project.  Stakeholder satisfaction improves because of the frequent feedback.  Some agile best practices such as timeboxing and prioritized user stories are easily adopted but others are harder.  In particular, some of the obstacles uncovered by the team are related to the corporate culture of consensus-building which Alex considers to be a non-negotiable part of the organization.  Abacus is infused with the values and personality that Alex has brought to the organization as its founder.  So when the team had trouble getting clarification on its work because the consensus-building process was taking too long, Alex simply told them to move on to less important work and come back to the other stuff when it was “ready”.

Over time, there were modest improvements in productivity and customer satisfaction at Abacus, and most of the project work was done with an agile approach using several agile best practices.  But any time a team encounters an obstacle that relates to the culture of the organization, the team loses.  Gradually, agile is treated as just another method, just another tool that may or may not be applicable to the work being done.

Brightstar

Brit researches Agile methods deeply and comes to understand that there is a process component, but also a meta-process component.  Brit decides that the potential benefit is huge: multiplying productivity, increasing morale enormously, and becoming a leader in the marketplace… but that the level of effort to get there is also large.  Agile is not a “silver bullet“.  Truly doing agile requires a deep cultural change in an organization and Brit is fully aware that changing cultures is enormously difficult.

To start things off, Brit decides that all work throughout the whole organization must take on an agile culture.  This is a culture that allows for experimentation and regular reflection and learning.  As well, Brit knows that like an athlete training for a major sporting event who gets a top-notch coach, Brightstar will also need a coach.  Internally driven culture change is even more difficult and since Brightstar isn’t in deep crisis, there isn’t as much motivation for staff to fundamentally change the way they work.  A coach will help to keep the motivation, vision, and encouragement flowing so that the corporate change will be sustainable.

Brit decides that the fundamental aspects of agile that need to be put in place are the timeboxed cycles of work that include a pause for reflection, learning and planning.  All types of work can be done in that framework.  The coach is responsible for helping the organization adopt this cycle of work and keeping at it until it becomes like a perfectly regular healthy heartbeat for the whole organization.

Finally, Brit announces to the organization that no opportunity for learning and improvement will be denied.  Over the course of several months, this is demonstrated by several interesting incidents where staff suggestions for obstacles to be removed are acted upon quickly and decisively.  Not every suggestion results in real improvement, but all the employees quickly get the message that the environment of learning is real, and the pace of suggestions increases as does the level of individuals taking initiative to make changes directly.

Within a year, productivity at Brightstar has soared.  There is an initial bump in staff turnover as some people who were there with an “it’s just a job” attitude moved on.  After the first year, employee staff turnover rates have decreased substantially, and can mostly be attributed to changes in personal circumstances such as marriages and deaths.

Brit gets it, and is willing to be hard-nosed about learning.  Learning about product, process and people.

A Plan for Agile Transformation

I’ve worked with quite a number of organizations trying to adopt agile and trying to do agile transformations.  In that time, I’ve seen some patterns.  I would like to describe the high-level pattern of what an organization does to make a successful agile transformation.  This overall plan must not be seen as a rigorous step-by-step procedure, thus using the term “wave” instead of “step” or “phase”.  It can be visualized thus:

Step One: Decision

The leader of the organization decides that agile is more than just another method of project management or product development, and that the vision of an agile organization is worth the effort to make a deep transformation throughout the entire organization.

Wave One: Just Start

The leader engages trainers/coaches to do the following things roughly simultaneously:

  • Introduce _everyone_ in the organization to agile concepts
  • Start _everyone_ in the organization using the agile meta-process
  • Start an Agile Transformation Team made from members of upper management to guide the overall transformation
  • Do initial cultural and process assessments to track progress over time

Wave Two: Capacity Building

The coaches and the Agile Transformation Team work with employees to develop a sufficient number of people who are capable agile facilitators.  They learn about agile methods more deeply: practices, principles, variations, techniques, and tools.  They learn to be effective facilitators who have the trust of their co-workers.  These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.

Wave Three: Sustainability

Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers.  These are the people who will take over from the external coaches.

As an ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes.  Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy.  The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail
This entry was posted in Uncategorized by Mishkin Berteig. Bookmark the permalink.

About Mishkin Berteig

Mishkin Berteig is a Baha'i, a father of four, a husband and an experienced Agile consultant and trainer. Mishkin is a Certified Scrum Trainer (CST) with the Scrum Alliance, a certified Master of OpenAgile wight he OpenAgile Centre for Learning and a certified SAFe Program Consultant (SPC) with the Scaled Agile Academy. Mishkin has a technical background including a B.Sc. in Computer Science and worked as a Chief Architect reporting to the CIO of Charles Schwab, but gave it up to be more Agile.

4 thoughts on “Agile Transformation vs. Agile Adoption

  1. Pingback: Tweets that mention Agile Transformation vs. Agile Adoption | Agile Advice - Working With Agile Methods (Scrum, OpenAgile, Lean) -- Topsy.com

  2. Pingback: Twitted by kschlab

  3. Pingback: An Agile Approach for Adopting Agile Practices | smoovejazz

  4. Pingback: Agile Transformation and the Chasm | Agile Advice – Working With Agile Methods (Scrum, OpenAgile, Lean)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>