How an Agile Transformation Might Go Off the Rails

Or, What Else Must Management Do for a Successful Agile Transformation?  

 

If you’ve decided to help champion an Agile transformation in your organization, let me just say: Kudos to you! It is well worthwhile in the long run, and your organization will truly feel like a modern, well-run organization. But don’t think for a second that this means it’s unlikely for your Agile transformation to go “off the rails” somehow.  

Chances are, at some point, it will.  

But here’s the good news: Given how many organizations have attempted such a transformation, it should be no surprise that there are some “usual suspects” that a savvy leader can anticipate and plan for. (Hopefully, that’s you!) But, fair warning: Doing that will likely require that you invest in some Agile leadership training for yourself (and other leaders in your organization).  

So, while the following lists are not exhaustive, we predict that they describe roughly half of the organizations out there that are stuck in their Agile transformation.  

What Must Management Do for a Successful Agile Transformation? Let’s State the Obvious First. 

Of course, one of the easiest ways for an Agile transformation to go off the rails is for it not to have a fighting chance to begin with. If your organization does not have buy-in from key stakeholders, for example, the chances of it succeeding are vanishingly small.  

So, at risk of stating what you already know, here is a list of things management must evaluate if they are having a problematic Agile transformation:  

#1: Have you established the motivation for the transformation? Motivation has two components: A reason for doing something, and a sense of urgency. If one or both are lacking, people will be unwilling to change. Have you adequately explained the reason for the Agile transformation? Have you made it a priority in your organization?  

#2: Is there a clear vision? Transformation is easier when everyone has a clear idea of what the end-state looks like. That includes how the transformation will impact both internal and external stakeholders. Have you communicated a vision for your organization’s Agile transformation?  

#3: Is there a clear road map? Here’s a great way to prevent Agile adoption: Drop off a few teams at a three-day Agile workshop and then expect, when they return, that they will simply start “doing Agile.” That’s like letting your contractor spend the weekend at a lumber yard and expecting them to return with a house. Yes, it’s an important step, but the house still has to be built. Be actively involved in developing an Agile roadmap with your teams so they have a better idea how to build that house. (But don’t micromanage—instead, help people understand their roles.) 

#4: Are you engaging all levels of leadership? Are project/product/portfolio managers being kept “in the loop” with all of the above? How about account managers? Is HR doing its part to recruit and/or train the talent you need?  

#5: What are you doing to break down organizational barriers? Siloes and fiefdoms are the antithesis of the Agile approach. What are you doing to break down barriers and improve collaboration? 

Why Agile Transformations Fail 

So, let’s suppose, for the sake of argument, that you’ve done all the above. You’ve communicated the reason and urgency for the Agile transformation, provided a vision and a roadmap, gotten the various managers on board with the process, and vowed to help eliminate any organizational barriers…and yet, things are still not where you would like them to be. 

What now?  

Here are three key reasons Agile transformations fail:  

Leaders don’t yet have a full grasp of Agile and its connotations. Here at Sketch Development Services, we’ve run into a lot of well-meaning (and very competent!) leaders who, through no fault of their own, still had some major misunderstandings about what Agile is, and what it really means for their organizations. It is up to them to show the way by getting fully educated on, and then adhering to, Agile principles.  

For example, executive leaders often traffic in long-term plans. These are based on perceived market trends as well as projections about what is scheduled to be released 8, 10, 12 months from now (or even longer into the future). But forcing these things will put strain on an agile team. Leaders have to trust their teams to identify the important work to be done and learn to be fluid in their planning.  

Another example: Leaders often make judgment calls about what work needs to be prioritized. But this, too, is something that has to be left to the teams. It might be tempting to simply walk down the hall and ask a few developers to pause what they are doing to tackle some hot new item…but you have to resist that temptation to disrupt the existing work backlog, wait until their sprint is over, and get that item into the next sprint time box.  

Misalignment between internal teams. There are a few different ways in which this can happen. One way is for Agile teams and traditional waterfall teams to be working under the same roof, so to speak—that is, working in the same portfolio, or on parts of the same project. If the non-Agile teams are making demands for things like, say, long-term projections, it creates a pressure for the Agile teams to revert to the previous way of doing things. The degree of that pressure increases when those non-Agile teams are not a part of Agile ceremonies, like planning and retrospectives. 

Another way in which there can be a mismatch between Agile teams and non-Agile ways of thinking is when it comes to marketing, sales, and business development. If your Agile team is focusing on just a handful of clients at a time, but your sales and marketing teams are bringing 20-30 new projects to the table through a traditional funnel, something is going to go awry.  

Overwhelmed product managers/owners. For Agile transformations to work, there need to be strong product managers/owners in place who have experience with Agile principles. All feature requests should pass through them, and they should have a strong voice in prioritizing work. For that reason, they also need to be good at organizing and prioritizing requests and ideas from multiple stakeholders. Good communication and organizational skills don’t hurt either. 

When the product manager/owner is not good at prioritizing work (and communicating why those priorities are the way they are), people will start working around the manager. It might feel, at first, like getting results faster. But trust us: That way chaos lies. 

Agile Training for Organizational Leaders 

So, we’re not saying that Agile transformations fail because of poor leadership…but they can recover with knowledgeable, proactive leadership. 

If we had to make a checklist of what good leaders do to support an Agile transformation, it would look something like this:  

  1. Have a good basic understanding of Agile values and principles 
  2. Learn how to best motivate an Agile workforce (and do so consistently) 
  3. Get good talent on board, and then harness that talent 
  4. Adjust to having a “support role” when it comes to product release planning 
  5. Work hard to align teams and break down barriers  

These might seem like simple, obvious steps to some. That simplicity, however, hides the fact that they are all learned skills that require training and practice. If you are interested in developing these skills for yourself, take a look at our Agile Leadership training or coaching services and reach out with any questions.  

Matt House

Matt is a recovering developer that still gets excited when hears the "Ribbit" of someone starting up Toad. After spending some time in the world of project management, Matt was convinced there had to be a better way to develop software. Once he attended his first agile boot camp he discovered that flowers smelled...

Other posts you might be interested in