It’s the question I know many people have when I first talk to them about their company’s agile transformation. It might take a little time to get the question out of them, but once we’ve built some trust, it comes tumbling out:
“I thought Agile was supposed to make us faster… what’s going on?”
That “what’s going on” part of the question can get filled out in a few different ways…
- Are we doing it right?
- How much longer until we see improvement?
- Were we misled?
- Is the issue that, maybe, Agile just isn’t for us?
…but, in the end, they all point to the same problem: The organization has spent valuable time and resources “becoming agile,” but they are not seeing the benefits. Their transformation has become stuck.
The premise of the question is correct: Yes, becoming an agile company should make you faster. You should be able to go to market more quickly, and be more adaptable to feedback and changing market conditions.
When an organization feels that it has done everything right with regards to an agile transformation and yet is not seeing these benefits, there’s a problem—a problem that we’ve seen over and over again.
Context: Three “Stages” of Product Development
Let’s diagnose this problem. To start, consider that creating and maintaining a product has historically followed a sequence that moves—generally speaking—from Business, to Development, to Delivery. (This is an oversimplification, of course, but it will do for the point I want to make.)
In this generalized model, the business stage represents all of the organizational effort spent before the actual development of a product begins. This includes defining requirements, gathering needed resources, and so on. All of these processes feed into the development stage, where the product itself is created and revised. The delivery stage sees the final testing and quality control (ideally) as well as implementation or delivery of the product (which may or may not be handled by separate product support and deployment team).
Business, Development, and Delivery activities exist whether you are practicing waterfall, using agile methods, or doing something else entirely. The main difference is that, in a waterfall environment, the three stages really are stages: Nothing gets done in development until all the requirements are signed off, and each stage is usually the responsibility of a separate part of the organization.
In an agile environment, the three are much more tightly coupled and happen in quick iterations—so, for example, the business is always revising user stories and using them as a springboard to communicate with development, development produces working software more quickly, so that delivery and feedback are frequent—if not continuous.
Now imagine what would happen if, say, the development teams started thinking and behaving the way that agile teams should, but business and delivery did not. What sorts of things would happen?
The Problem: Hyperfocus
Unfortunately, not much imagination is required.
As an agile coach, I see this happen time and again: Organizations pour all of their budget and energy into making their development teams agile, but do very little to include the business and delivery teams. So those teams default to what they’ve always done, and friction gets introduced into the system where change meets inertia. It doesn’t take long for the agile teams to start feeling burned out on the transformation.
What does this look like from the outside? Let’s look at these broadly-defined stages one at a time, thinking about what would happen if it lagged the others throughout a transformation:
The Business Stage. The lagging business stage spends large amounts of time “gathering all the requirements” and getting them right before even speaking to the developers. Development teams feel like they are sitting around waiting for requirements to come in. And even when they have the requirements, they are delivered in a huge tome of a document. There are no productive conversations between the teams around these requirements.
The Development Stage. It’s rare, but sometimes the development teams lag behind—they are agile in name only. The term “agile” comes to be seen as just the latest fad that management introduces, but everyone still works in a non-agile way. Meanwhile, the delivery part of the organization might be going full-bore DevOps.
The Delivery Stage. Product capabilities are handed off to a different group for deployment. But that group becomes overwhelmed by the pace that the development team is setting; they are like a warehouse with goods piled at the shipping dock, ready to go out, but only one truck can park at the dock at a time.
It’s easy to see how “Agile” would fail to lead to a faster, more flexible organization in each of these cases. In fact, introducing agile practices in just one place would only create friction in the system. The agile transformation would then grind to a halt.
What Not to Do When the Speed Isn’t There
Here’s what not to do if this is the question in the back of your mind: Double-down.
Too many organizations who see their agile transformation stall reason that they need to redouble their efforts. That’s not illogical. But then they look to see where the agile transformation has had the greatest uptake, and find it in the one area where agile principles were consistently applied— usually the development teams.
So the organization concentrates, again, on the stage that is the strongest. And again, the needle doesn’t budge.
It’s like trying to resolve a traffic jam by accelerating the cars smack in the middle of it. All that will happen is a series of fender-benders, at best.
What to Do Instead
So what’s the alternative?
First, it’s worth taking a step back and getting a feel for all three stages—the entire flow, if you will. Don’t just focus on what the development team is doing. Look at other functions, too: Sales, business development, account reps, QA teams, and so on.
Second, you need the right tools to pinpoint where value is truly being added, and where work is slowing down. I discuss one such tool in our Webinar, Why Your Company is On Its Third Agile Transformation…and how to make this one stick.
Third, be prepared for some pushback. Your company might still feel that agile transformation is a “development only” or “IT only” kind of change. They might not understand (yet) why they need to transform what they do, too.
There might even be some resentment if people come to think (mistakenly) that they’re having to change because development “isn’t doing their part.” If the goal of agile transformation is business agility, then it’s up to company leadership to make it clear that what is needed is a business-wide transformation.
In short, it takes some real strategic thinking and cultural alignment to reap the benefits of agile transformations, especially when it comes to speed. Just like our traffic jam example: When someone has a bird’s eye view of what’s going on, traffic can be rerouted easily and the jam overcome. But if you tell the people in the middle of the jam to floor it? The results are kind of inevitable.
