Last post
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?
Comments