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.
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.
Image credit: unsplash.com