Agile Failures: 3 Common Missteps That Kill Transformations – Part 2

In my previous post, I talked about the main agile failures I see with failed transformations, which is thinking that the process is some kind of magic wand that will make everything perfect. And we know that’s not the case (or you wouldn’t be reading this blog post). in this post, I want to tackle the second misstep – that of the organization. Rather, how the organization impacts the transformation, either by helping facilitate it or by hindering it.

Misstep #2: The Organization

So the first question I need to answer is – what do I mean by the organization? There are two things that I see that are relevant – the structure of the organization and the politics and power dynamics that are supported by it. Agile failures are common when the organizational issues aren’t addressed.

Organizational Structure

Most companies are organized around functional areas. Whether it’s R&D versus Manufacturing  (like we had at Hewlett-Packard) or IT versus QA versus Operations, companies tend to align along those functional breaks. It’s not inherently a bad thing. But when we’re creating agile teams, we need to focus on more than just development or QA or operations. We need to create a cross-functional team capable of delivering everything described in the user stories. And we need to try – very hard – to move beyond layers of work (database, middle tier, front end, etc.).

Cross-Silo Teams
Cross-Silo Teams

Instead, we need to create teams that are matrixed from the different functional silos we defined. Our teams should consist of all of the skill sets needed. Like the diagram on the right, we need to bring in people from all disciplines that support the product we’re delivering. That may be very hard, because of how management sees their role versus how their role needs to evolve.

Power Dynamics and Politics

Many companies have inherent political influence or power based on the size of the organization that reports to someone. A vice-president with twenty direct reports may be less influential or have less power than one with forty. Some of these paradigms are decades old, but they still negatively impact how we create and manage our agile teams. People who feel that their sense of self-worth (perhaps just business-related but for many, it’s far beyond that) is based on this perceived power they hold. And some of those people are more interested in expanding their fiefdoms than helping the business and product succeed.

And Finally – Focusing on Just IT

Many companies look at agile as just changing the handle on the crank of the machinery to generate software. They don’t think that any other parts of the company will need to change to support a transformation. If all you want to do is have your development teams work in smaller chunks of work then yes – you’re probably right. But if you want to get the full benefits that agile and lean thinking can provide to your company, it’s going to mean a lot of changes to a lot of different functions. Finance. Human Resources. Even legal and executive teams. If we can move beyond the “Just IT” mindset, our companies can achieve even better results and gain a sense of alignment and purpose that many aspire to attain.

How Do We Solve This?

Agile failures are common, especially in large organizations. Most companies that we hold up as success stories are small, nimble, and lean. The main thing to do is to make sure that we’re clear about the impact an agile transformation is going to have on the entire company, not just one department or functional area. The main customer-facing people are going to need to collaborate with the development teams on a daily basis. They need to get to the heart of customer needs, not just wants. It’s a very difficult role, but it’s critical that we focus on the things the customer needs now so we can be effective at meeting those needs.

Another piece is understanding that management (which I’ll get to next post) and the other departments recognize how what they’re doing may be negatively impacting our ability to create a sustainable agile transformation. Funding projects, not teams. Focusing on rewarding individuals. Establishing year-long goals that don’t reflect the higher purpose and vision of the company. All of these things are long-established policies and procedures that need to change to support the transformation.

And finally, we need companies and cultures to move beyond the political and power games that occupy so much of our mental bandwidth. The goal should always be on providing the greatest value to our customers, not how many direct reports someone has. Or how much golf they play with the executives. And I don’t want to give the impression that economics is the only goal. Our employees – in order to generate and maintain engagement – want to contribute to something greater than themselves. How about asking management to contribute to that conversation?

Closing Thoughts

Organizational issues are one of the main areas I’m focusing on these days. There are so many failed agile implementations, primarily because organizations don’t recognize the changes that are needed to create truly impactful and long-lived transformations. Most people think that agile means we’re just changing the handle on the crank of development machinery. We’re replacing that old, broken, wooden one with a nice new, shiny, mother-of-pearl-inlay one. And when they come back and see an elevator button panel and no gears, it looks like agile didn’t work right because their expectations weren’t met. But we didn’t set those expectations properly.

That’s one of the parts of the mission for Artemis. We focus on clear communication and making sure those expectations are set properly. Focus on just IT will give you a little boost, but you won’t be on the path to sustainable transformation. And your agile failures will just continue to pile up.

Happy coaching, my friends!

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.