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.

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?