If Agile Isn't the Point, What Is?

For you guys that have been following this blog a while, you know that I am interested in how we become agile in larger, more complex enterprises. Inevitably when I am out doing one of my talks, I'll get the question: How do I convince my upper management that this whole agile thing is a good idea. My advice... you don't. My bet is that your upper management doesn't care at all if you are able to adopt agile. When our play is how to adopt agile... we are focusing on the wrong things.

But, if management doesn't care about adopting agile, what do they care about?

I'd bet your management cares that you can't get any working product out the door. I bet they care that you are consistently late and over budget. I bet they care your product has terrible quality and doesn't satisfy the needs needs of your most important customers. I would bet your upper management would like to be able to change their minds, easily figure out how to insert new projects into the queue, and have some reliable understanding of what products they can deliver to market over the next six months.

Going agile is only relevant to upper management to the extent that you can map your proposed changes to value that is going to drive business outcomes. These may not be the outcomes that you care about... they have to be the outcomes that your manager cares about. We have to use language that is relevant to them and helps them meet their goals. So when I get asked how to convince a manager to let the team go agile... my advice is try and understand how your management team defines success and suggest practices that are going to help them get there.

Unless they can map investment in agile to a specific business outcome, and ultimately financial return, you are fighting a losing battle.

Subscribe to Leading Agile

Stability first... then speed!

So many folks want to flip a switch and magically become agile. They want all the benefits without any of the hard work that comes along with really transforming the organization. People think that just because they read a book... or took a few days of training... that they can expect instant productivity. They don't realize that agile methods only show you your problems... it is still up to you to fix them.

I'll often see this thinking manifest in questions like "how many iterations until I can expect my team's velocity to start going up". There is so much underneath a question like that, it's hard to give a solid answer. Is there a prioritized product backlog? Is there a product owner grooming the backlog and available to the team? Is the team cross-functional? Are they dedicated to the project? Do they have everything they need to be successful? Are there external dependencies?

All those things matter... and right out of the gate.. you are not quite sure the kind of impact those answers will have on the team's ability to deliver.

My recommendation is generally to look at team performance in three phases. The first goal is to measure what is... to establish a performance baseline. Next start thinking about getting stable... stable performance is key to running a predictable agile project. Once you are stable... now you can start thinking about getting faster. Adopting agile is a learning process and you can't improve a system when you don't understand what is broken.

And that is really the key... it isn't about getting a better velocity. It's about fixing the broken parts of your organization. It's about looking at where you are and comparing it against where you would really like to be. It's about understanding the impediments standing in your way and dealing with them in a meaningful way... in a way that really, truly helps the team get better. It's about getting more efficient at creating value and really improving the processes that allow value to be created.

Those kinds of answers don't translate into a great marketing pitch. How long will it take to get agile? I don't know... how many iterations will it take to remove the organizational impediments that are slowing the team down? How many iterations will it take until you are willing to fix what is really broken? How many iterations until we are ready to stop applying labels and start REALLY transforming the organization?

Subscribe to Leading Agile

Are we Overly Compliant?

Post before last... I made the point that companies often have a hard time adopting agile because their management structures are not in alignment with their corporate objectives. We have project managers and resource managers and product managers. We have teams of specialists matrixed into product teams and project teams and component teams.

Each team has its own set of objectives... their own sets of metrics... and each are pulling the company in oftentimes competing directions. To create an agile organization... we need to get our core systems in alignment... we need to move toward common goals and objectives.

Legislation and Policy versus Intent

Paul Boos did a nice reply to my post and brought up a great point. Sometimes all those policies and metrics and such are self-inflicted. Paul works in the government and tells a great story about how legislation transforms from some idea with some worthy intent into a set of misguided policies and metrics at the department and agency levels.

Congress passes a law stating that government IT projects must have an Enterprise Architecture. The Office of Management and Budget then decides that all departments have to use their common architectural framework to be in compliance with the law Congress just passed. When Paul's particular department gets a hold of the legislation... and the guidance from the OMB... they determine that all technical decisions have to be passed through their governance committees. It's a way to make sure the USDA complies with the regulation coming down from on high. Now when Paul's specific agency get's a hold of the policy decision... they determine that the team is only allowed to use specific technologies that are already approved by the USDA and the OMB.

(NOTE: I slightly revised the previous paragraph to more closely reflect Paul's intent, and the way the government actually works... this is an oversimplified example by the way ;-)

The intent of the law was to foster collaboration and reuse between departments but gets implemented as a set of draconian policies that limit creativity and innovation. What would happen if we could rethink some of the policy and metrics and focus more on the desired outcomes?

Corporate Audits

Before I joined VersionOne I worked for CheckFree Corporation here in Atlanta (since acquired by Fiserv). Our PMO had put all these big tollgates in place so that our projects could pass audit. As our team was trying to drive agile into the organization... we would constantly get push back because our agile projects couldn't pass audit given we didn't have the right documentation at the right time to pass the formal tollgates.

Come to find out... the auditors didn't care about our tollgates... they only cared about our paperwork because we told them that was the process we used to create software. They didn't care that we used waterfall or PMI or RUP or whatever... they just cared that we followed the processes we had said we were going to follow. If we told them we were changing our process... they would hold us accountable to the new standard... and as a matter of fact... that is just what we did.

We took a fresh look at the audit process and established a framework that could be configured project to project. The new framework enabled traditional software lifecycles and agile lifecycles to coexist and both were able to pass an audit. By focusing on what we needed to accomplish... rather than how it was being accomplished... we were able to focus on optimizing the outcome rather than optimizing the existing processes we were using to get the outcome.

Monkeys and Bananas

Have you guys ever heard the story of the Monkeys and the Bananas? I sourced the story here... it is relevant to our conversation so here goes...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

Are we Overly Compliant?

So... how much of what we are doing is because we're a bunch of monkeys that don't know any better? How much of what we are doing is because it's the way things have always been done? How much of what we are doing is based on our interpretation of the law rather than from a firm understanding of the intent behind the law?

Have we taken the time to really assess these constraints and figure out what needs to change to accommodate our agile transformation?

Subscribe to Leading Agile

Subscribe to Leading Agile