After coaching several clients on their Agile journey, I have found that establishing certain circumstances significantly improves chances of success. The following five have an especially massive impact on the success or failure odds of an Agile transformation initiative.

1) CEO Support

CEO sponsorship is unquestionably the biggest single difference maker when introducing Agile; if the fairy godmother of Agile granted me only one wish, that is what I would use it on. I have coached clients where the top executives took no part in the Agile transformation, apart from maybe blessing it halfheartedly from the get go. I have also worked with top executives and CEOs who have been truly passionate about championing the Agile mindset and values and it makes all the difference in the world.

Introducing Agile is much more than getting people in the same room with a stack of post-its. To get the full benefits, it affects culture, leadership style, budgeting, and HR practices, just to name a few significant areas. Without an executive sponsor that truly believes in, and champions these changes, it’s very hard to harvest other benefits than becoming more efficient at developing software solutions.

2) Having a Compelling Vision

Why are we introducing Agile? As the going gets tough, it’s important to remind ourselves why we started on the Agile journey in the first place. Are we looking for more innovation, closer connections with customers, increased engagement, shorter time to market, higher quality products, to survive as a company, or maybe something completely different? With a compelling, easy-to-communicate vision, the risk of trying to do it all at once, or shift focus too often, diminished significantly.

3) A Cross-Organizational Transformation Team

The first thing we always do at Ugilic is to advocate the creation of a cross-organizational transformation team. As I discussed earlier, introducing Agile will potentially affect many parts of how you run and develop your business. Having HR, business, IT and the leadership team represented in the Transformation Team will make tackling some of the challenges you will face a lot less painful. I have previously worked with transformation teams consisting purely of IT people. It probably comes as no huge surprise that it was at a company where the CEO showed little interest in Agile.

The upside with starting with an IT only transformation team is that it often gets off the ground quicker because of less organizational complexity (and politics). Unfortunately, the quick start often hits you like a boomerang later when trying to involve the business, HR, and other functions. The people in these functions will need time to understand the impact of Agile on their domain. They also sometimes react with an it-wasn’t-invented-by-us attitude or find that some of the decisions that made perfect sense in IT don’t scale to the rest of the organization.

4) Experienced Scrum Masters

At a recent client, I experienced something I have never tried before. Instead of coaching and growing new Scrum Masters from within the company, they hired two experienced Scrum Masters for the first two pilot teams. The effect was massive. Instead of spending most of my time teaching the Scrum Masters about Agile and how to facilitate the teams, I could concentrate on working with the transformation team and the managers on creating the optimal conditions for adopting Agile.

There are so many benefits, and a few pitfalls, from hiring experienced Scrum Masters, that it deserves a separate post…to be continued.

5) Dedication to Technical Excellence

The final thing I want to touch on is how care and attention to technical excellence impact organizational Agility. In my experience, teams that invest in and pay attention to technical practices, like test-driven development, refactoring, automated build and deploy, continuous design and clean code can change direction much more easily when needed.

Unfortunately, these best practices of software craftsmanship are not common in all teams and once the team must deliver working software every two to four weeks, they are challenged by hard-to-change code, time wasted debugging, unstable solutions, extensive manual testing, and long stabilization efforts.

As Agile is all about adaptiveness and responding to change, teams should combine Agile governing frameworks like Scrum with Agile engineering practices that can help the team keep their work at a high quality and in a flexible state.

Final Thoughts

To make Agile stick at most organizations, it’s vital to embrace the Agile values and principles and challenge the this-is-how-we-have-always-done-things-around-here thinking that often dominates. If one or more of the five circumstances discussed above can be established during the early stages of introducing Agile, it’s my experience that the journey to true business Agility will be a less bumpy and much more enjoyable ride.

If you want to hear more about my experiences, please feel free to reach out. As always, I would love to hear your thoughts in the comments below.

2 Comments

Martin – what’s your take on transformation vs. scaling of agile? I see organisations preemting their transformation and cultural integration of agile in teams and individuals with a full-blown scaled model. While I clearly understand why organisations tend to focus on the scaling issues early on, there’s real danger that agile values will not be practiced given the top-down nature of how scaled models are rolled out. Do you have some insights into how an org-wide transformation dovetails with scaling? Maybe some examples of an approach that avoided stretching the chaotic phases of change?

Unfortunately, I have seen many organizations confuse Agile adoption with scaling or starting to scale Agile before the foundation was strong enough to carry the load. If the values and principles are not yet part of the culture and the quality of the product is inadequate, you will also scale these challenges when you start scaling, and that will only make them even harder to solve.

The best examples of successfully adopting and scaling Agile I have witnessed are organizations that 1) clearly understood that it’s two completely different things 2) organized the teams in a way that limited the need for scaling to a minimum and 3) scaled in an Agile manner – meaning starting out with the simplest setup that could possibly work and continuously adapted it based on concrete experience.