Skip to main content

Are we Overly Compliant?

Mike Cottmeyer Chief Executive Officer
Reading: 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?

Next Dancing at Starbucks

Comments (5)

  1. Bob Williams
    Reply

    If we are so self focused on improving the existing 'process' then it's easy to get into the "We've always done it that way" syndrome. I agree, the best way to solve for this is to continue to ask "What are we trying to accomplish?", "What's our goal?". This keeps the innovation alive and will deliver results in a more agile manner.

    Reply
  2. Paul Boos
    Reply

    Thanks for following on this Mike.

    One minor correction; OMB is a policy establishing organization in the Executive branch (not the Legislative where Congress is). They take and interpret laws and create the (hopefully consistent) policy that will ensure the rest of the Government meets the intent of the law. They also act as the overall Government's auditors, but not as detailed as you describe it.

    Your auditing is perfect; we establish a set of complex processes that we say we comply with and then get beat up for not following them. We NEVER think that we should simplify the process (LEAN it out…); we think we need to add more controls to ensure everyone follows the complex process, thus making it more complex!

    It doesn't take a rocket scientist to figure out that as we do this, we make it harder and harder for us to perform at the level of expectations to our business counterparts (who just want a working system to make their job easier) and the public.

    We're getting some successes here, but usually I end up having to run interference for my Scrum teams and do some (unnecessary) clean-up afterwards. I like Admiral Grace Hopper's philosophy of better to ask for forgiveness than for permission; in general as long as the decision-making is ethical, then it is legal as well.

    Cheers and thanks for the post!
    Paul

    Reply
  3. Mike Cottmeyer
    Reply

    I knew I should have had you read my summary before I posted… oh well. I'm happy I got it that right ;-)

    Thanks for cleaning it up for me!

    Reply
  4. Mike Cottmeyer
    Reply

    I changed the language in the post a bit… let me know if I got it right this time… or at least close enought ;-)

    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.

    Reply

Leave a comment

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