Where Should You Start Your Transformation Journey? Part 1 of 3

Lessons from the Trenches

I could very easily title this post Lessons Learned from the Trenches, because I have definitely been in the trenches of various Agile Transformations and I have learned a ton along the way. I’ve learned that an Agile Transformation is HARD WORK and you need to have a ton of Agile Grit and endurance to be successful. One thing a transformation shares in common with a typical project, is that it will never go exactly as planned. And that’s Ok, as long as you can steer clear of becoming scrumerfall or any other Waterfall-Agile Hybrid. Assuming a transformation is incrementally moving forward and staying true to the goal of becoming Agile, then navigating the bumps along the way isn’t the end of the world.

The Agile Teams Approach

The primary thing I’ve learned about an Agile Transformation is that the ultimate price tag and overall timeline is going to be based entirely on where the transformation starts or how it starts. The size of the organization is also a variable. The most expensive and time consuming transformations are large enterprises that attempt an IT only transformation by adopting team level scrum. Large enterprises present the most complex ecosystems and have the largest number of internal processes that are designed to support waterfall delivery. Starting with team level scrum in that type of environment is very challenging. Teams will continue to face a vast array of external challenges that will thwart every attempt at practicing Agility. The error in this transformation is thinking that the organization’s current challenges are somehow related to the team’s performance, or worse yet – the team’s productivity.

The Agile Projects Approach

Another challenging attempt at transformation is when an organization of any size, attempts to adopt Agile on the back of “Agile Projects”. This scenario plays out when an organization is attempting to transform by picking projects that it believes are good candidates for Agile. This approach to transformation doesn’t carry the same heavy expense as the previous example, but it is still a very slow approach. Generally, the selected project or projects already contain the same risks that any project has with regard to fixed date, fixed scope, and fixed budget. And when the project starts to get the least bit off-track, the organization in this scenario will generally revert back to what they know best and the Agile wheels will come flying off the bus. The error in this approach is thinking that work needs to be transformed instead of people or teams. And the exact opposite is true.

The Hybrid Framework Approach

This attempt at transformation is probably my least favorite. In this example an organization has made the investment to adopt a framework, but has put it in the hands of people who think they are smarter than the Agile minds that created the framework. In this example, the people responsible for implementing the framework see it as a buffet of Agile options that they can “pick and choose” from. But in this pick-and-choose approach, what they are really doing is combining the most non-agile parts of the current method of delivery, with the easiest parts of the framework. Once the pick-and-choose approach catches on, then everyone quickly gets on-board. What typically wins out in this approach is the legacy command and control leadership style. The end result is that none of the benefits of the framework are realized, a lot of money and time is wasted, and everyone takes a great big gulp of the scrummerfall kool aid. The error in this approach is thinking that frameworks are buffets, when in fact a framework’s success is based on its full adoption. I’m not aware of a framework is designed to be sorta implemented.

The Going Rogue Approach

An approach that can actually work in small pockets, is the Going Rogue approach. This approach doesn’t exactly fit into a typical attempt at Transformation, but it is a common way that organizations will attempt to adopt Agile. This approach is when a group or department decide that they are going Agile and they are out to prove that Agile is the way to go. I give a ton of credit to those that take this approach. These are your true Agile champions – the ones that have Agile in their blood – they know all the positive outcomes related to successfully adopting Agile. And their likelihood of success is high – but limited. They will see results – but most of the organization will continue to sit on the sidelines until some other force comes along and pushes them to adopt Agile as well. Ultimately, the going rogue approach is another attempt at Transformation that is very slow.

So what’s the lesson in all of this?

The lesson here is that where a transformation starts in an organization matters and it matters a lot. And even if an Agile framework is being leveraged, if implemented in an organization incorrectly or on an invalid premise, the framework will not yield the results and the organization will blame the framework or believe that Agile just isn’t right for their organization. Even if an organization implements an Agile Transformation Office or a Lean Agile Center of Excellence, if the foundation of the transformation is flawed to begin with, then the transformation journey will be long and the price tag will be high.

This post is part 1 of a 3 part series. Part 1 is building a case that where you start an agile transformation matters. Part 2 will present different ways an organization can start a transformation successfully. And part 3 will provide alternative approaches to an Agile Transformation – like fixing what’s currently not working.