10 dos and don’ts of agile transitions

Change is hard. There is no denying that an agile transition is a major change, and subsequently, hard. In fact, there has never been an easy agile transition. Every agile transition that has ever taken place has led to a dip in performance, and every future agile transition will lead to a dip in performance. We know this because transitions have been studied for years. Transitions over time can be visually represented, like this:

A common pitfall of inexperienced IT professionals is assuming everything will slowly improve over time, or that combining agile with the waterfall methodology to create a hybrid will give you the best of both worlds. This seductive illusion is known as wagile.

To help you in your transition to agile, we’ve put together a list of ten dos and don’ts. To succeed in any transition, you need to let go of the old ways of doing things first, so let’s start with a “don’t.”

A common pitfall to many agile transformations is when leaders send development teams to agile training prior to beginning their transition. While training on a new methodology is intuitive and responsible, providing training before they’re really ready causes multiple problems. You risk the potential of a resistant team member derailing the upskilling efforts and demotivating the entire team. It’s also likely that your team will retain very little of the training because they don’t have enough buy-in or context. In fact, we estimate that only 5-15% of the training will be retained, at best, if provided too early. Because time and budgets are not unlimited, it’s important to get the most out of yours by providing your team training only after you’ve received their buy-in to the transition.

Once you’ve reached that point, invest in upskilling the entire team. Even if many of them are familiar with agile, make formal training a team-wide priority. It will align your team on terms and processes—which improves communication and decreases weaponization—and serves as the foundation for a successful transition.

The most critical step to any successful transition is understanding why the change is needed. Each individual needs to understand the benefits agile offers and what’s personally in it for them. This broad communication should come from leadership and set clear expectations and benefits. If you apply agile to the wrong situation, the result is confusion and resistance. You may even have someone dig their heels into the ground on a future, proper, transition. When applied correctly, agile offers teams the ability to deliver and obtain customer feedback faster, while providing those customers partial value right away. Compare that to a waterfall project, where customers wait months and years to receive value—and where the delivery often doesn’t meet the customers’ ever-changing needs. Another reason to consider transitioning to agile is that many businesses can simply no longer survive by doing things the old (slow) way.

As with any large change, your agile transition will be met with its fair share of resistance. Some people resist for the right reason: they don’t understand how the change will help and believe things should remain as they are for the success of the organization. Others will resist because they don’t want to make the effort of learning something new, don’t want to risk failing, don’t want to lose their “expert” status, are afraid of the unknown or a thousand other reasons. It’s your responsibility as the leader to manage resistance to change. Be aware of defiant behavior and address it promptly. It has the ability to spread quickly, especially when the individual curbing your efforts is one of the “best” people on the team and a person others look up to. If it comes down to it, you may even need to part ways with some of your best people if they can’t commit to agile.

Fortunately, most people want to succeed and only require guidance in their journey to the new agile reality. The important thing here is to actively listen to their concerns. This cannot occur if leaders are always bouncing between meetings; availability and approachability are key. As the agile transition leader, it’s up to you to create an environment with enough trust and opportunity for people to open up about their concerns and difficulties. You need to have a good understanding of the informal organization and empathetic leaders alongside you to guide the transition. Address concerns by looking for win-win scenarios, but…

There comes a time in every agile transition where the resolve of the organization to transition to agile is tested. Sure, it’s easy to delegate decision-making authority when there is ample budget available and the products are doing well. But what happens if things become less utopian? When under pressure, people tend to revert to what they are used to, which unfortunately is often still command and control style management. When a project or program gets into trouble, resist the urge to “take back control.” It can set back the agile transition multiple iterations and shatter the perception of management’s commitment to making the transition work, thus deflating the transition's biggest supporters.

When programs and projects struggle, trust the process and exploit the continuous improvement mechanisms of agile frameworks to learn about what isn’t working and make things better for the next iteration. Instead of taking control of the project, leaders in the organization should stick to the process and make sure all of the prerequisites like trust, rich communication, and actual time and budget for continuous improvement are in place. This might cut into the effective execution time, but it’s critical for the long-term survival of your agile transition.

We have yet to meet an organization that starts an agile transition on the basis that they are standard and straightforward. Every company is different and has unique people and processes, which is a good thing! When looking at agile transitions, you should consider that supporting frameworks take this into account—even out of the box. Instead of tailoring your frameworks before your transition has even started, start out of the box and then use the continuous improvement mechanisms of your framework to start tailoring your agile implementation to your unique environment.

During your agile journey, you’ll likely face many situations where you’ll need to make compromises. Perhaps your vendors don’t have their processes aligned to an agile framework and you need to accommodate their waterfall delivery methods. Or perhaps there are legal limits to the amount of decision-making power you can distribute to the teams. If the level of ambition of your agile transition starts off low, the end result will be even lower. Start as ambitious as possible; subtleties and tradeoffs can be made later.

In your agile transition, you’re bound to experience a state of wagile. Don’t be naïve and think you can avoid it, but do try to escape it as quickly as possible. Being stuck in a perpetual state of wagile, where a team never fully lets go of the waterfall methodology, leads to the worst of both worlds. While you’re in wagile, resistors will say agile is failing. Supporters will get frustrated and eventually leave. However, the truth is that agile hasn’t been fully implemented. Follow the advice above to quickly exit the dreaded state of wagile and you will find yourself being agile and providing value to your organization like never before.

Leading an agile transition may be one of the most difficult but necessary tasks you take on to help your organization thrive in today’s environment. Now that you know the top dos and don’ts, you’re ready to build your plan, put it into action and weather the wagile and adoption phases.

About authors

Kevin Miller

Kevin's mission is to close the gap between IT departments and the businesses they support by opening IT to change. His goal is not to change what IT does; it’s to change how IT does it by changing how IT thinks. Kevin's expertise is helping organizations of all sizes adopt and embrace agile methodologies for faster deliveries, reduced cost and increased customer satisfaction. He holds numerous degrees and certifications, and has more than 20 years of progressive experience in a wide range of technical areas, including software development, operations, project management and leadership.

Tommy van Schaik

Born and raised in the Netherlands, Tommy van Schaik found out early on that his natural habitat was between business and IT. Having earned a Bachelor in Business & IT and later a Master in Business Process Management & IT, he worked most his career for the Dutch Department of Defense. There he focused on project management, IT governance, business processes, IT architecture, requirement engineering and business rules. After a beautiful expat adventure in the United States, Tommy has now moved back to the Netherlands where he is employed as a project manager for the Dutch government.