5 Common Mistakes in Agile Transformations

DZone 's Guide to

5 Common Mistakes in Agile Transformations

An Agile Coach reflects on the ways he's seen Agile transformations go awry, and what teams can do to correct these mistakes.

· Agile Zone ·
Free Resource

Over many years, we've found ourselves called into organizations to help after they've attempted an Agile transformation. Things hadn't quite worked out the way they'd hoped and then, through a recommendation, they'll find themselves talking to us. Every time we go in, we see some common reasons why their transformation failed. Here are 5 common mistakes behind these failed attempts, often made on the advice of the company they entrusted to guide them. Hopefully, you can use these insights to avoid similar mistakes or, if these seem familiar, get back on a better path...

  1. Big-bang change
  2. Agile as an end, not a means
  3. Ticking the Agile boxes
  4. Training as a software upgrade
  5. Thinking your transformation is done

Mistake 1 - Big-Bang Change

This is often a consequence of buying "Agile in a Box." A sure sign of this is when people talk about "The Agile Methodology" or "Our Agile Process." The very first value statement of the Agile Manifesto is "We value Individuals and Interactions over Processes and Tools."

Agile is a mindset, not a process. Nonetheless, many organizations take on a branded methodology wholesale, introducing many new practices simultaneously. They then see productivity drop through the floor and deadlines jeopardized. The entire pilot program struggles to take on unfamiliar practices while trying to deliver to a schedule that assumes an instantaneous improvement. In reality, they experience the inevitable dip in performance, management panics, changes are reverted before they can have a positive effect or continued in a suboptimal manner and we hear the common refrain, "We tried Agile and it didn't work."

What Might We Do Instead?

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. - 12th Principle of the Agile Manifesto

Instead of a big-bang change, we can make a series of small changes. These could be small changes across teams or a large change in one small area (e.g. creating a pioneering or pilot team to explore new ways of working). Each small change gives us time to reflect on what's working and what isn't. We identify our current pain points and bottlenecks in our existing process and try small experiments to alleviate those issues. Don't assume that copying the practices of other organizations will help you with your problems, in your context.

For more on this, see "Our Tack on Effective Change."

Mistake 2 - Agile as an End, Not a Means

Many business journals sell Agile as a panacea. They say it's the strategy your organization needs to adopt if it wants to keep pace with or outmaneuver the competition. Attempting to "implement" Agile as an end in itself is unlikely to have the results promised. It's a journey, a mode of transport, not a destination. And it is more than a strategy, it usually means a fundamental cultural change in the organization. As Peter Drucker said, "culture eats strategy for breakfast."

What Might We Do Instead?

First, it's important to understand what success looks like for you. What do you want to see happen as a result? Do you want to innovate more, creating new products and services in your portfolio to grow revenue? Do you want to bring products to market sooner? Do you want to flatten or reduce the cost of change in your existing systems? Or, all of the above? When seen as a destination, it's too easy to mistake Agile as a new process for people to follow. Agile is a lens through which we can see opportunities to achieve our end goals we couldn't see before. These opportunities are not just in the outputs of your organization, they span People, Product, and Process.

Mistake 3 - Ticking the Boxes

Many organizations claim to be agile or claim to have tried implementing Agile and it failed. Often this is due to treating Agile as a box-ticking exercise: Daily Standups - Check, Occasional Retro - Check, "Stories" in Jira - Check. These practices have value in a certain context, but if they are being done without an understanding of the value we are hoping to achieve from them, then they are no better than a Cargo Cult. In this story, hoping to invoke aircraft supply drops...

"Islanders imitated the practices of US soldiers. They carved headphones from wood and wore them while sitting in fabricated control towers. They waved landing signals while standing on the runways. They lit fires to light up runways."

What the islanders didn't understand is that the soldiers did these things because the planes were coming. Doing those things would not cause the planes to come.

Another sign of this phenomenon is Anaemic Standups - where the team is simply updating a project manager on the work completed since yesterday, rather than synchronizing and creating serendipitous learning opportunities. This is the team ticking the "we have a meeting where we stand-up" box.

What Might We Do Instead?

If we don't understand why we're doing a practice, then it will be inefficient at best and potentially harmful at worst. We can ask ourselves the question "What is the problem that this practice is trying to solve?" If the answer is "That's just the way we do it," or "That's what it says in the book," then we might look to do something differently.

Our approach is to identify our current biggest obstacle and think of something we can try over a short period of time to relieve that obstacle. Then we'd review; is it still the biggest obstacle? If not, repeat for the next obstacle. If it is, try another experiment. All the while, avoiding any big-bang change.

Mistake 4 - Training as a Software Upgrade

Could you imagine going on a two-day course on playing the piano and afterward being good enough to perform professionally? We've seen many companies treat Agile training like this. After a two day Test Driven Development course, they expect their developers to perform at a professional level on their first day back. Despite the presumed simplicity of TDD, it actually takes a deep competency that takes skill to do well.

With computers, we can upload new software, perform the upgrade, and expect instant performance improvements, but this isn't how people learn. A short course can introduce ideas and show people the first steps on their journey to becoming competent. It then takes months (or years) of daily, deliberate practice to become competent and certainly years to master.

What Might We Do Instead?

Just like learning a new musical instrument, you need time between lessons to practice. Each lesson then becomes a coaching session where the music teacher gives you feedback about where your performance is today. They help you find improvements. Between lessons, you may not even learn a whole piece. You may only get part way there and your task until the next session is to learn the next part of the piece and improve your expression in what you've already learned.

Training can be used as an introduction, or a taster session, to a new skill. It will take practice and coaching to master that skill and apply it. Eventually, you'll be ready to perform professionally. Regular follow-up coaching and allowing your team space to practice is key to taking your team from their first step in a training course to professional levels of competency.

Mistake 5 - Thinking Your Transformation Is Done

It can be quite disconcerting to realize that a transformation is never really done. Whatever solutions that we have today are based on our knowledge now, the context that we are in and the problems that we are solving. Any one of these things can change, and render our existing system inefficient or ineffective. By understanding that there are no such things as "Best Practices," only "The best that we currently know," we can keep ourselves flexible when our circumstances change.

"It is not the strongest or the most intelligent who will survive but those who can best manage change." ― Leon C. Megginson

Both the values and principles of the Agile Manifesto point to the continuity of the process. Individuals and interactions over processes and tools highlights that dogmatic adherence to a process at the expense of individuals and interactions is "not Agile." Responding to change over following a plan applies just as much to our processes as to our deliverables. Recall the 12th Principle of the Agile Manifesto mentioned earlier.

What Might We Do Instead?

Remember that the process is never complete. The context that we adapted for yesterday might not be appropriate today and might be harmful to our survival tomorrow. Continue to reflect on what is making us effective and what is less than ideal; sense, adapt, and tune our behavior to better fit our current context.

agile, agile adoption, agile coaching, agile teams, agile transformation

Published at DZone with permission of Andy Palmer , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}