Tuesday, December 4, 2012

Why do we need agile resilience?

Hey, CMMI Appraiser, why do we need agile resilience? ~ Agile DC Conference participant 

Most readers are aware that this CMMI Appraiser spends a lot of time and energy speaking all over the country (and planet) about issues that are most important to engineering and software professionals today. One of the hottest issues right now is how to make agile stronger against opposing forces -- or, to coin a phrase, how to create “agile resilience.”
Why do we need agile resilience? This question was raised at the Agile DC conference last month, where my topic was using CMMI to make agile stronger. A QA Director told me that she thought adding too much structure to agile would ruin the purity of the agile method.

“Ruin the purity of agile?” I replied, pressing my hand on my heart. “Madam, I am a gentleman!”

She laughed, but her statement raised a serious issue.

As I explained in my session, many practitioners of agile are concerned that a performance improvement framework like CMMI is contrary to the spirit of agile. But nothing could be further from the truth.

What is resilience, anyway? The formal definition says resilience is power or ability to return to the original form or position after being bent, compressed, or stretched; elasticity. It is also described as the ability to recover readily from illness, depression, adversity or the like; buoyancy.

I believe these are two very apt definitions of resilience, given what is happening in our market and the influence of some of the newer players – such as the federal government, and big defense contractors – who are demanding that their vendors “go agile.”

In my opinion, this why we need a resilient model. Right now, agile is a loose collection of methods and tools, by definition. And, yes, there’s a lot of fear in our industry that too much structure will cause problems.

But the simple truth is this. If we want agile to remain agile, we need to agree on a resilient model that can withstand all of the attempts of these new players to change our values. It is time to start building resilient agile architecture.

Now, I’m not suggesting that we have an industry model, because I’m not sure that is useful. The history of industry models are that they lead to certifications, assessments and examinations and so on and so forth. That is not useful. But I am suggesting that we have a loose framework that we can all agree to. And it starts with a philosophy.

As we all well know, agile is just something that you are. It’s a philosophy; it’s a way of thinking; it’s a way of life. To be agile is to adopt agile values, the values of collaboration of personal responsibility, of having the right team members, of failing fast, and all of the agile values from the Agile Manifesto and various articles and books that have been written by some of the great thinkers in our industry like Jim Highsmith, Ken Schwaber, Ron Jefferies, Jeff Sutherland, and others.

By contrast, the CMMI is not something you are. The CMMI is something you use to strengthen what you are. In the context of agile, the CMMI helps you strengthen what you are by helping you build a resilient framework.  And by embracing lessons of CMMI with agile or Waterfall or Spiral – or whatever your methodology of choice is – you move closer to being a great company.

The time is now for agile resilience.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about running a successful CMMI program.


Neil Ernst said...

When you say "not useful" are you implicitly saying it is "waste" in the Lean sense?

Jeff Dalton said...

Neil, not EXACTLY, but in the end it brings about improved usefulness of the process.

I use the word useful to describe a way of doing work that helps an engineer get the job done, with no (or little) perceived overhead.

One could go down the "waste-walk" in a lean sense, and develop a process that isn't useful at all - as misguided as that sounds it happens all the time!

So what I am implicitly saying is that a useful process is a "lean process" that is embraced by an engineer (or PM, et al) as helping them get their work done. Think of it as Lean+.

While Agile methods appear to be "lean" they are not always useful in getting the job done, in and of themselves. CMMI and help make Agile useful - if you focus on the usefulness, and not the compliance.