Problem: Enterprise Change Control vs. Agile Project Metrics

For agile to be truly successful, we have to use it successfully on projects in enterprise companies. Start-ups, small shops, even small groups flying under the radar at big firms are all great but they can’t be characterized as enterprise adoption. So what will it take?

I wish there was a simple answer or at least a sequence of steps to follow. There’s not. But, there is one element that is common to many enterprises and must be dealt with. That element is enterprise change management.

Big companies have committees that control (some would say prevent) change. They go by names like Change Control Board, Project Management Office, Change Police, etc. (sorry, that last one isn’t real…I think). They may seem to be in the business of blocking change but their goal is (or should be) to help prioritize projects, optimize resource usage and enforce consistent policies across projects.

Managing priorities and resources is fine. It’s the ‘consistent policies’ part that is the problem.

From an enterprise reporting perspective, consistency makes sense. How can you compare completely different, unrelated projects? You have them report standard (i.e. traditional) metrics in standard formats.

Of course, agile projects don’t rely on traditional metrics. We don’t estimate with lines of code or function points. We don’t plan with hundreds of pages in requirements documents and functional specifications. We don’t have old style milestones like code complete and starting SQA.

Like it or not, we have to find a way to work with the enterprise change folks. Fighting them will only result in your project getting roadblocked.

We have to identify what really matters to them. What information do they absolutely need to do their jobs? The answer will be different from enterprise to enterprise. Once you know what they need, find a way to deliver it to them while maintaining as much agility as you can.

Negotiate. Try to arrive at metrics that you can reasonably deliver AND are meaningful to the enterprise.

Do not attempt to use both waterfall and an agile approach like Scrum so you can report waterfall metrics while developing with Scrum. You’ll be asking for trouble. It may work but it will be costly and counter-productive.

Eventually, as agile gains traction and broad support, this problem will work itself out. The enterprise change folks will identify agile metrics. They will either define a standard set of metrics across all projects or operate with two metric sets, one for traditional projects and one for agile projects.

It will be their choice and our gain.