A starting point for a discussion on marrying Agile methods and CMMI.
27May

Truly Agile CMMI


The team room of a truly lean/agile company doing CMMI in a way that is natural to them and authentic.  They are doing CMMI in an agile way.  They know no other way to do it.  They went from "what is CMMI?" to ML2 in 14 weeks.  Their commitment to lean gave them an edge many companies wish they had: a culture of value and excellence.

What does "truly agile CMMI" look like?

Well, it looks like a commitment to adding value, for one.  It looks like delivering incrementally and using each incremental deliverable to iterate, learn, reflect, and continuously integrate into the whole.

It looks like questioning everything that you don’t understand until you do, and then basing decisions on what will provide the most benefit without adding unnecessary features, functions, or work.  It also looks like being true to your collaborative nature, to your culture of learning, to your behaviors of communication and transparency.  It looks like using measures to know where you are and how well you’re doing.  It looks like a commitment to to doing nothing for the sake of doing it — either it has a benefit that you can reap, or it’s not done.  It looks like building practices into what you do in a way that eliminates the need for waste-riddled, ceremonial audits later.

When every effort has a purpose that you can tie to a business benefit; when every task delivers something someone needs or wants; when you create a system that people want and use, that you don’t have to pull teeth to get people to adopt and provide you feedback on; that not only flows with and follows in-line with your natural ways of working but promotes new ideas and ways of changing your work regularly and distributing those ideas to everyone who wants to know…. when not a single result of some effort exists whose only reason to exist is to provide evidence for an appraisal….

*THAT’S* what truly agile CMMI looks like.

It’s not just in the processes that result from using CMMI, but also in the manner in which those processes were created.

You don’t "do CMMI" in an agile way when you’re a stogy traditional-oriented organization, and you don’t achieve an agile CMMI when your implementation approach is traditional.  If you’re an agile organization, incorporate CMMI in an agile way.  Don’t abandon agile values and principles to implement CMMI.  Exploit your agile values and principles to implement CMMI in a kick-ass way.

CMMI in an agile way, an agile approach to CMMI, and a seamless blending of CMMI with agile approaches doesn’t happen (easily) if your approach to AgileCMMI isn’t lean and agile.

30Apr

FREE Business Book for all bloggers


Delivering Happiness: A Path to Profits, Passion, and PurposeI’d like to let everyone know about an opportunity to:

- Make a difference

- Read a great book

- Get FREE extra copies of the book to give to friends and/or your blog readers, and

- Help raise the bar for work-life excellence!

Go here:

http://www.deliveringhappinessbook.com/contact/apply-for-an-advance-copy/

to sign up and get your free copy to read and (usually) free extra copy to give away.

They’re operating on the honor system that you will blog, tweet, or otherwise spread the word about the book.

As you can see in the URL of the link… The book is about Delivering Happiness. It’s the story behind Zappos.com from its current CEO, Tony Hsieh.

I’ve received my free copies and I’ve read it. It’s truly inspiring and has excellent stories. I’m now working my way through one of the books he refers-to called Tribal Leadership, and there’s another work as a result of reading his book called The Happiness Hypothesis which I’ll be reading after Tribal Leadership.  I’ll be blogging about the book on (or about) June 7th.

Tony’s on a mission to change the face of business.

So far, so good.

 

Tweeters follow @dhbook

Learn more about the book here:
http://www.deliveringhappinessbook.com

Advance order here:
http://www.amazon.com/deliveringhappiness

22Apr

Decisions without Data


As many people know, for the six days ending Tuesday this week, the UK along with much of Europe has been in a virtual travel “lock-down” when it comes to commercial turbine-engine air travel.

The instigation of this situation has been the eruption of the Eyjafjallajökull volcano in Iceland last week whose plume of ash and debris was carried by the wind and jet stream straight over to Europe.

We humans are no match for one-two-punch of geology and meteorology, but how we respond to events such as these is entirely within our control.  It appears that the collective wisdom in Europe had no contingency planning for what to do in this sort of situation.  As a result, the air-space lock-down went on for days — many argue, now, it should not have lasted more than 48 hours, and, should never have resulted in a nearly system-wide blanket closure of air-space in most of Europe under any circumstances.

But even the lack of a plan for what to do isn’t the underlying cause, but merely a symptom of the root cause:

No defined standards, and, decision-making despite a lack of data.

As early as Saturday, 17 April, airlines were conducting their own flight tests with actual (but empty) passenger aircraft, and were returning information regarding the flight conditions in several places in Europe.  By Sunday, at least four major airlines had conducted their own flight tests and were beginning to compare data and report the same thing: There are many places where it is not safe to fly, but there are *more* places where it is safe to fly and we should work out a way to exploit these places.

What sort of data was prompting aviation and meteorological officials in Europe to keep the sky closed?

Weather RADAR data and satellite imagery.

Weather RADAR data and satellite imagery showed an ash cloud spreading over Europe.  On the face of things, this would prompt most rational thinkers to do what Europe did: progressively shut-down the airspace as the cloud made its way across Europe.  (Ash-laden air doesn’t make for good compressible, combustible materials in air-breathing engines, not to mention the damage it would cause in the works.)  However, since when did “on the face of things” ever really prove to be enough information?

There were two problems with using weather RADAR and satellite imagery both as a basis of determining the impact of the ash, and, as a source of data for making decisions:

  1. It doesn’t give you an accurate sense of proportion or density, and
  2. It can mislead you into seeing a more serious situation than exists.

What does weather RADAR look for?
Water.

How deep into an ash cloud can weather RADAR see?
Not far past the outer boundary.

What does ash look like on a weather RADAR?
A solid block of lead.

How much ash density does it take for weather RADAR to freak-out and “see” a massive block of solid ash?
Not much at all.

OK, so now we’ve established that using weather RADAR alone isn’t sufficient from which to be making decisions, let’s move our discussion to a simpler, but more pervasive gap in Europe’s air-traffic planning:

They had no established standards for how much ash in the air is enough ash to cause them to shut-down commercial aviation and bring businesses, commerce, and economies around the globe to a serious, sputtering stall, (not to neglect the stranding of hundreds of thousands of people all over the planet, including myself), and putting many plans, deals, and families into a tail-spin.

Even when European agencies did send aircraft to the air to test it, they didn’t know whether the data they brought back was telling them things were safe or unsafe.  They assumed “any ash is bad”.  It wasn’t until the airlines got together with engine and airframe manufacturers to look at the data collected by the airlines themselves and use the governments’ meteorological data to come up with “safe” standards for air-ash-density, that the collective governments (the last of whom were in the UK and Ireland) decided to lift the air ban in a dramatic change-of-position late on Tuesday evening (European time).

Let me summarize:

  1. No standards.
  2. Data collected but not meaningful.
  3. Empirical data collected by equipment not intended for how it was being used and interpreted without true insight (literally).
  4. Decisions being made anyway.

What I’ve skipped in this post is all discussion of contingency planning, continuity planning, and challenges with communicating across dozens of countries, laws, and decision-making structures.  Much of which were all gummed up throughout this mess for lack of thinking things through before the ash hit the turbo-fans.

The focus, here, however is on one crucial point, forget planning, because none of it would have mattered:

Europe was making decisions without data.

Are you?

Copyright Agile CMMI Blog

CMMI, and SCAMPI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

WordPress Theme by: Wood Street, Inc.

Facebook Twitter