How to Enable Agile Adoption in Your Organization

For years I’ve been lecturing and writing about the process of adopting Agile. Specifically, I’ve been promoting a model that Stephen Forte and I call the “Agile Buffet” where change, in this case the usage of Agile practices on a team, is pulled into the team incrementally based on real observable needs. I’m certainly not the first to suggest such models as organizational change is a heavily researched and written about topic. I entitled this post “How to Enable Agile Adoption in Your Organization” for a reason. First, I feel that I find myself glossing over some of the real challenges that teams have when facing change. Second, the adoption of change, even when it comes to Agile adoption, is rooted in basic organizational change techniques.

Make no mistake – organizational change is tough. There are many forms of change within an organization; from reorganization of a company due to an acquisition, management change or even the adoption of different practices to help with efficiencies or innovation. Many organizations fear change – they feel that change is disruptive causing a loss in productivity. Some managers mistakenly believe that if they can just keep people focused on their day to day job organizational changes are less impactful and disruptive. Unfortunately, this leads to a downward spiral where change can actually become impossible or very painful (a self-fulfilling prophesy). The truth of the matter is that a great organization is constantly changing. In fact, one of the characteristics of amazing organizations is how well people within that organization embrace and usher in change.

There is only one constant in the universe – and that is change. You and your organization/team/division (whatever scope you want to work in) only need to be good at ONE thing – and that’s managing change. The rest is trivial.

Shocking Reality

I first started to get passionate about organizational change when I began to adopt Agile practices on my own teams. I was shocked at how much resistance there was. These practices made total sense to me – it was a no-brainer for me to jump right in and adopt EVERYTHING Agile – yet for others there was much skepticism and even resistance (and in some cases out right sabotage). It was then that I realized that I couldn’t just push practices on to people – I had to start with the reason those practices made sense. My team needed to have the same common perspective as I had before introducing these changes.

Another reason I started to become passionate about the method behind agile adoption was that I got tired and angry listening to other agile zealots preaching things like “you can’t be Agile if you don’t practice Test Driven Development” or “if you aren’t following 100% of every agile practice ever invented, you’re still not Agile”. Deep down I knew that this was totally incorrect. This eutopic perfection that was being preached just didn’t seem achievable for 99.9% of the organizations I’ve ever worked with as a consultant and trainer. Being Agile simply wasn’t an on/off switch.

Recently, the process of Agile adoption has come to the forefront as Gartner has recently expressed that Agile is close to entering the “Trough of Disallusionment” in its Hype Cycle. This is an symptom of how difficult organizations have found the adoption of agile due to the nature of the organization and people within it. This has been further reinforced by surveys from VersionOne that highlighted statistics such as “53% of companies thought that organizational culture was a barrior to the adoption of Agile practice and that 41% of companies believed that there was simply a general resistence to change.

I’m now certain that the process by which teams adopt Agile is more important than the Agile practices we want them to follow.

Inception

I compare organizational change to eating. You can’t force food down someone’s throat.. they will just spit it back up.. and you don’t want them to get violently sick all over you!!!!. That’s bad. If you wanted someone to eat, get them hungry and then put food in front of them (healthy food of course). This is where the term Agile Buffet came from. The goal is to have teams get hungry (deeply recognize that a problem exists) and then to make sure that the buffet contains exactly what they need to be satisfied (Agile practices). In this case, change is pulled versus pushed.

I affectionately call this process “Inception” after the movie. The entire plot of the movie centers around planting a thought into someone’s subconscious to get them moving down a course that would impact the future. When you “start with the why” you are in fact planting the seed of change and causing hunger to grow. Only when there is hunger (usually in the form of pain) change happens.

In reality, change in this way can only be stimulated by pain or gain. That’s the only true reasons that anyone would change any of their behavior or practices. They want to either eliminate pain or have something that they didn’t have before. The common element between pain and gain is emotion. Thus, managing change is much more about managing emotion than it is fixing a broken system. Unlike computers or assembly lines – you can’t simply “fix” a human system without recognizing the human qualities that got it there – and the most important human quality is emotion. Managing emotions is really what Inception is all about.

This may sound wishy washy – but it’s not. I’ve experienced organizational change in many ways for the past 20 years – and it comes down to the same design pattern over and over again. Humans are not robots or assembly lines – pure logic and metrics don’t always prevail as change motivators.

Setting Up for Change

I entitled this post “5 Steps to Enable Agile Adoption” because I actually wanted to focus on what is required to start inception (remember, inception is simply about making sure that people involved within the change deeply connect emotionally with the need). What needs to be in place even before you start making changes to your organization is a shockingly simple pattern – yet is amazingly absent from most change management approaches.

The first thing you should realize is that organizational change doesn’t happen by accident. Even when it does, it’s probably not the organizational change you want to see. The first step to enable an environment to stimulate and control change is to breathe some life into it and make it a continuous project onto itself. The method of process improvement must exist both outside and inside all other initiatives. Just like every project, you need an environment first – hence this post.

Here is a definition of a simple environment that you need to have in place prior to any form of organizational change (provided you are going to be driving that change incrementally). If you have ever worked with me, you’ll probably realize that this is the only pattern I ever follow and that the closer I follow it – the more success I have with change.

1. Establish an initial “change team”: Depending on the scope of your organizational change – this could be easy or a hard thing to do. For example, for a project team wanting to adopt Agile practices, this team may be the entire team. For an organization that wants to adopt new HR practices, this may initially start off with a subset of the HR and Management teams and then slowly expand to a broader audience once change begins to have momentum. In almost all cases, the initial team will start small and then over time will expand to more people as the scope of the change increases and momentum builds. In almost all cases, people are pulled into this team based on the scope of change that they can impact.
2. Establish a cadence of structured dialog with your team: Before any change happens, you must create an environment of engagement with your team. This this form of engagement is about having a full and untethered dialog between team members. This cadence should be the heartbeat of the team and should follow the same “pattern” every time. Here is a pattern that you can use for this dialog cadence:
   
   

   a. Timeboxed, high bandwidth discussion. These discussions can happen weekly to start and then move to a longer cadence cycle if required, however, the span between these discussions should never exceed one month. By high bandwidth I mean in-person if possible. If not in-person, then video conference, voice, etc. Try to avoid other electronic means such as email or shared chat.

   b. Start the session with a round table. For each person ask the following
   
      - What they have been working on during the last period
      - What they plan on delivering during the next period
      - What things may have gotten in their way

   c. The participants should then engage in a retrospective where the following is discussed:
   
      - What is working well
      - What is not working
      - What are the biggest impediments
      - What are the biggest opportunities
      - What should be the focus for next round of improvement

   The nature and structure of these meetings can and will often rapidly change over time. For example, as teams mature they may want to change the meeting format to focus more on the flow of work rather than doing a round table. They key is to establish a pattern of conversation with a focus on improvement. Make a list of things the team wants to stop doing. Make a list of the things the team feels they need to start doing. In most organizations there is a lot of low hanging fruit that can be addressed without the need for more complex methodologies.

3. Track progress and accountability: This should be a no-brainer. This cadence of discussion drives ideas that drive action. This should be tracked. It doesn’t even matter what tool you use – from Excel to more mature work tracking tools. The bottom line is that you should be tracking everyone’s ideas as well as tracking the actions and accountabilities that follow. This tracking list should help drive the further discussion of improvement and helps to ensure that the work required to make change is properly tracked.
4. Measure… everything: It is very important for teams to have a clear view of the metrics associated with the changes you want to impose. The team should work together to help define the key indicators and the trend they want to see for each indicator. For example, you may be introducing changes to sales practices and in this case would want to measure metrics like leads per month, conversions, sales volume, and sales cycle time. Agile teams do this all the time measuring aspects such as velocity, bug rates, change rates – working together every month to slowly fine-tune practices to remove waste and become more efficient. In fact, a lot of what comes out of early meetings are actions that revolve around establishing a base of measurement. Many organizations simply aren’t measuring enough to use data to drive many decisions – they key from this step is that measurement will help drive decisions of organizational change and many of the early actions are going to focus on collecting and communicating measurement.
5. Share… everything: This is perhaps one of the most important aspects of the environment required for change. The entire team should know as much as possible about at the scope of the intended organizational change. Only by sharing all information with the wider group can everyone resonate in the same direction of change. Of course, you will still have some things you just can’t share such as HR sensitive material or sensitive customer data – however, ensuring that everyone is on the same page with information helps to align the team as well as to solicit effective problem solving by the entire team.

When you implement this environment (which is a change in on itself) you create something I call a “change tuned environment” – where the entire organization is “tuned into” incremental change.

Some organizations I’ve worked with start more formally by doing an assessment about some future desired state, doing a gap analysis and then attempt to plot change. For me, this has never been effective. Start by having a simple and continuous dialog. Teams should get into the habit of making smaller changes first and this is why I promote focusing on “low hanging fruit” – because any positive change is still positive and emotionally enforcing at the beginning of this process. Sometimes tackling the biggest issues within the organization makes it easy for teams to feel a lack of progress when in reality it is much more important to start the change flywheel spinning.

Simple Pattern of Empowering Leadership

What’s really great about this design pattern is that just by following it you are working in a direction that will lead to you working yourself out of a job. In fact, the goal of every manager and leader should be to work yourself out of a job. Wow hey? If you do this, you become an empowering leader who can scale decision making while at the same time create an environment that is ever evolving and learning. In fact, this is exactly what the book “Good to Great” talks about. Great companies have this culture and values something called a “Level 5 Leader”. Simply stated, a Level 5 Leader facilitates an environment I just described by empowering all around them.

Patterns of Change

There are, of course, other methods that facilitate organizational change. One of my favorite is the Kanban Method formalized by David Anderson. In reality, there isn’t much new in any of these methods that hasn’t been adopted in the world of Lean Thinking (which stemmed from Lean Manufacturing that stemmed from the Toyota Product Method, which stemmed from Deming’s principles) or a derivative like the Theory of Constraints. The crazy reality is that we don’t have to reinvent the wheel when it comes to how to do organizational change – it’s been perfected for the past 30 years. We just have to embrace these practices and follow them ourselves.

With that said, if you distill these methods down you get the same design pattern – one that promotes incremental small changes that are continuous over time and managed discretely. It’s not rocket surgery but when it comes to managing a human system, emotions and perception is deeply impactful.

Of course, what almost every single one of these very successful models boils down to is what Taiichi Ohno called Kaizen in the Toyota Product Method. It has become the foundation and core principle of my entire career and management style. So, whether you are following Goldratt’s Five Focusing Steps to achieving the Theory of Constraints or the Kanban Method, or even more focused methods such as Scrum.org’s Agility Path, you will need to lay a simple foundation down first – and its this foundation that will get change to manifest and stick. Establishing this environment is the first change – and is usually done from “the top down” – the goal is to ensure that all future change are manifested and delivered via facilitation instead of command and control. Unfortunately, this first change might not be done in a collaborative way – but its nature will likely not be thought of as a negative change.

Before Change, Create the Environment

Whatever pattern of change you want to institutionalize, you must have the correct environment first. Without an environment that allows change to self-realize, organizational change will not stick and will deteriorate into confrontation and dissidence. In fact, this is my one simple litmus test for any organization or team. If I sense any form of discontent or expressions of “us versus them” or claims of “stupid management” or an overly expressive emotional response – I know that the only thing that was missing was the environment of change.

Whether you are adopting Agile practices or want to simply improve your division or team in some other way, start with these 5 steps – and you will realize much greater success.

And finally here are some important links:

• http://en.wikipedia.org/wiki/W._Edwards_Deming 
• http://en.wikipedia.org/wiki/Kaizen
• http://en.wikipedia.org/wiki/Taiichi_Ohno
• http://www.djaa.com/blog
• http://www.dbrmfg.co.nz/Bottom%20Line%20Accounting%20for%20Change%205%20Step.htm
• http://www.agility-path.com/