Five Circumstances that Will Act Like Rocket Fuel for Your Agile Transformation

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

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 blessing it halfheartedly. I have also worked with top executives and CEOs who have been genuinely 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, to name a few significant areas. Without an executive sponsor that genuinely believes in and champions these changes, it’s tough 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 shifting the focus too often, diminished significantly.

3) A Cross-organizational transformation team

The first thing we always do at Ugilic is to advocate creating 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 less painful. I have previously worked with transformation teams consisting purely of IT people. It probably comes as no massive surprise that it was at a company where the CEO showed little interest in Agile.

The upside of 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 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 had 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 to create the optimal conditions for adopting Agile.

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 quickly.

Unfortunately, these best software craftsmanship practices are not standard in all teams. Once the team must deliver working software every two to four weeks, they often run into problems like hard-to-change code, time-consuming debugging, unstable solutions, extensive manual testing, and long stabilization efforts.

Agile is all about adaptiveness and responding to change. Teams should combine Agile governing frameworks like Scrum with Agile engineering practices to help the team be flexible and deliver high-quality work.

Final thoughts

It is vital to embrace the Agile values and principles and challenge the this-is-how-we-have-always-done-things-around-here thinking to make Agile work. Focusing on the five circumstances discussed above during the early stages of introducing Agile, it’s my experience that the journey to true business Agility will be less bumpy and a much more enjoyable ride.

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

Image credit:


  • Maz Spork

    December 2, 2016 at 08:25

    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?


    • Martin

      December 2, 2016 at 16:08

      Awesome point and question Maz,

      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.


Leave a Reply

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