Archive for the ‘Culture’ Category

Doing Agile CMMI without “Doing” Agile or CMMI

Monday, November 8th, 2010

There’s an under-appreciated reality of what either agile or CMMI can accomplish for an organization.  In particular, it’s not as much about what either accomplishes for an organization as much as it is about what an organization does for itself that achieves agility and systemic improvement.

It seems to be a decades-old issue that many technology-oriented companies, and, it seems, especially software companies, struggle with organizing and managing operations towards excellence.  I can’t even begin to dig into any reasons why this is so, but there may be some truth to the stereotype about technology people not being good with business and/or people. ;-)

I’ve found something fascinating that is fairly consistent across many companies I’ve visited or discussed with colleagues.  What’s fascinating about it is not only the consistency across multiple fields, industries, verticals, and national boundaries, but that it reinforces a position I’ve taken since beginning my career.  That position is the afore-mentioned “under-appreciated reality”:

Aligning the organization with specific business goals and providing a supportive culture
leads to broad behaviors at all levels that result in high performance.

OK.  So, that may not seem earth-shattering.  But there’s a lot in this statement about agile and CMMI that too many organizations to “get”.  And, this is where all the anecdotal evidence from the many companies comes into play:

Organizations with a culture of excellence generate behaviors (including setting and pursuing specific business goals) that achieve agility and systemic improvement without specifically setting out to achieve either “agile” or “CMMI”.

Throughout my earlier career, I was routinely frustrated by “training” that provided me with specific tools and techniques for dealing with “many common” situations – pretty much all of which were cultural, interpersonal, and otherwise based on human behavior.  The cases, examples, and solutions all felt very canned and contrived.  Why?  Because, in effect, they were.  They were very specific to the context and would only solve issues in that context.  What the examples lacked – and by extension, the entire course – was fundamental tools with which to deal with situations that were not neatly boxed into the provided context.  In other words, these training courses provided practices. These practices work in explicit situations, but they fail to provide the basis upon which those practices were built.  Without such a basis, I and other consumers of this “training” could not address real situations that didn’t match the training’s canned scenarios.

“Doing” agile or CMMI by “doing” their respective practices results in exactly the same limited benefits.

Making agile or CMMI “about agile” or “about CMMI” accomplishes little value and lots of frustration.  These are only practices.  Practices are devoid of context.  A culture of excellence and an explicit business case to pursue improvements provide the necessary context.

We see this all the time.  For example, for decades in the West mathematics was taught in a way left many students wondering, “what will I do with this?”  (This may still be true in many places.)  It was/is taught without any context to how it can help them better analyze and understand their world.  As a result, Western students have historically been less interested in math, do less well in math tests, and are less inclined to study in fields heavily dependent on math.  All due to being taught math for math’s sake and not as a means to a beneficial end.

Medicine is also taught this way around the world.  Leading too many doctors to seeing patients as packages “symptoms” and “illnesses” rather than as people who need help.  Scientific exploration often gets caught up in the same quandary.  Exploration is the goal, if you’re looking for a specific answer, it’s research.  When you’re trying to create a specific solution it’s development.  Mixing-up “exploration” with R&D will frequently result in missing interesting findings in pursuit of narrow objectives.

In agile practices, what’s more important: doing Scrum or delivering value?  Pair programming, or reducing defects?  Maximizing code coverage in unit tests or testing the right parts of the product?  “Doing” Scrum, pairing, and automating unit tests are intended to deliver more product of high value, sooner.  Focusing on the practices and not what’s best for the customer are missing the point of these practices.  Same with CMMI.

What are the economics of your core operation?  Not just what your group costs to operate on a monthly basis, but what unit of value is produced for any given unit of time?  How do you know?  Why do you believe your data is reliable?  The ability to make decisions relies on data and when the data is unreliable, decisions, plans and anything else that relies on the data is questionable and risky.

It turns out (not surprisingly) that when a group focuses on what’s important AND has the economic data to reliably understand the behavior of their operation, it aligns their actions with the very same goals set-forth in both agile and CMMI.

Focusing on the right things in your operation will cause behaviors that achieve agility and “rate well” against CMMI.  Whether or not you’re even trying to “do” agile or CMMI.

Happiness is not an edict.

Monday, June 7th, 2010

I make a living helping companies improve their performance.  Bar none, the absolute hardest challenge is dealing with outdated, defunct, and proven-failed management and leadership attitudes and techniques.  It’s even harder when leaders won’t let go of them. 

Attitudes that don’t account for the emotional needs of people. 

Attitudes that don’t start with the fundamental requirement that tough or large changes require the top-down example and behavior to lead the way.

Attitudes that don’t stand up for what’s right and acquiesce to blatant cognitive dissonance.

Attitudes that fail to realize you can’t lay-out the company’s supposed mission or vision, or the staff’s objectives and goals, and not provide them with the tools or empowerment to make anything happen — or worse, to undermine efforts with behaviors and decisions that conflict with the messages.

Attitudes that perpetually fail to create sustainable results, superior performance, and legendary relationships among the company staff, and between the company and its suppliers and customers; yet they are the same attitudes that failure-destined leaders continue to retread in some insane hope or expectation that everything will work out on its own.

Well, here’s some not-so-profound news (which I’m pretty sure you didn’t need me to tell you): these attitudes are nothing short of leadership’s inability to own up to their responsibilities and accountability for actually doing what they’re there to do: lead

Instead of leading you’ll often find such cowardly executives hiding behind backbone-belying excuses such as "I lead through delegation" (which, when said by these leaders actually means, "I really don’t know what to do to help you get your job done"), or "I trust my people to do the right thing" (which, when said by such leaders, actually means, "I’m lucky my people know what they’re doing because I don’t"), or "I’m serious about quality, I’ve made Joe, here, the company quality sheriff" (which is poser-leader-speak for, "I haven’t the foggiest idea what drives quality in our company and but it’s a problem and I don’t know how to fix it, but getting someone else to blame is a lot easier than getting mixed-up with all that touchy-feely stuff.").

Such leaders are nothing more than overpaid, over-indulged and over-honored paper-pushers whose lack of involvement in day-to-day operations is probably a blessing.  Because, when they do get involved (especially considering their only natural inclination is to micro-manage if/when they bother), they typically don’t make things better.

In a profound way, most companies’ leaders simply don’t "get it", they won’t admit that they don’t get it, and they’re not open to having anyone help them get it. 

One the basic "its" they don’t *get* is that what’s going on in their company is a culture, and because they don’t see what’s going on as a culture, or appreciate the role culture plays in making a business successful, they not only don’t see that what they need is to change the culture, but that in order to do so they must lead the change themselves. 

Furthermore, they don’t see that what it means to change the culture is not to pass down new rules or to disseminate a verbal memo through subordinates, it means to get out and lead.  To behave or simply *BE* the new culture.  How flat does a new, great-sounding idea fall when it’s delivered in the same mechanisms as all the old, not-as-great (dare I say "dumb") ideas?

Do you agree? 

Perhaps you need validation of your way of thinking. 
Perhaps you need an example to follow.
Perhaps you need to crystallize your thoughts so you can pave a path.
Or perhaps you need something to believe in, something to help you find a better way to work, place to work, or how to start making a difference in your work life and work-life balance.

Maybe you’re someone who’s been burned trying such non-traditional ideas and you’re seeking what might have been missing, or a simple reflection on a point you didn’t see or know to look for.

In any case, if you are seeking how to understand and positively influence culture as a primary business driver of positive change and astounding accomplishments, then Tony’ Hseih’s Delivering Happiness is a must read.  Scratch that.  If you’re reading this review this far you MUST read.  Delivering Happiness.  Even if you’re currently not big on culture as a business driver, or, if you think you know about culture and business but secretly, deep down, you really have no clue what it is, how it looks, or how to create the one you want, you must read this book.  If you *know* your business has a culture problem but don’t know what to do about it, read this book.

The amazing things Tony and his team have accomplished by putting _happiness_ at the center of their existence and by making it unmistakably simple to lead by example will leave you wondering why it’s taken anyone this long to put this sort of content together.  There is nothing new in leading by example.  It’s talked about, written about, lectured about in every credible business and management venue anywhere at any time in history.  But, one thing (of many others) unique in Tony’s book is that he actually conveys _what_that_looks_like_.  It’s not just words to him and his team.  It’s how they *are*.  It’s in everything they do and say and consider.  They wanted a certain culture?  They *became* that culture and started every action from there.  It’s in how they treat each other, their customers, their suppliers, their partners and their extended relationships.  They want to sustain that culture?  They *built* and *rebuilt* their existence to continually refine what it takes to generate the culture they want.  Delivering Happiness is like being the ultimate "fly on the wall" to get the insight into answering the question most business books and theories frustratingly fail to answer, "OK, I get what you /describe/, but what did you *do*?!"  This book lays it out.

Delivering Happiness will probably make you wonder why bother with any other business approach, and even why bother with any other business book!  It’s as though all you ever wanted to know about running a business and making people happy (either as one, the other, or both) are in his 272-page first offering.  I’m not saying other business books don’t matter, and that other business books don’t have valuable insights and concepts.  What I’m saying is that Delivering Happiness is so fundamental that it almost makes no sense to start elsewhere.  If business leaders don’t understand the fundamentals of the role culture plays in their success and what to do to generate the culture they want, then little else can help.

Tony’s done great research.  Thanks (or no thanks?) to Delivering Happiness, my reading list has not only grown, but has sprouted an entirely new branch of exploration.  It’s fascinating stuff.  I was so intrigued I rescheduled several days’ plans to finish-up some of the reading I had already started so I could clear my reading time and my mind for the new stuff Tony introduced me to.

Get it here.

Not only does Tony make an eloquent and convincing case for the influence and effects of business culture, but his amazing story about and the insights from places he worked or owned before — as they all relate to _happiness_ — are inspiring and instructive — for anyone with an open mind. 

And… not the kind of "open mind" that rationalizes nonsense, but the kind of open mind that’s open to questioning tradition; asking where a tradition came from and why it continues to exist despite its time having come and gone.  The kind of open mind that’s continually seeking better ideas built on progress and results, not on reactionary fears, theory, or short-term thinking.  And, the kind of open mind that’s ready to make a really big difference in their work, life, or in the world, and not cling to stale thinking born of a time when those old ideas were once new.

It’s time to replace those ideas with ideas built in and for the 21st Century.  It’s time for ideas that deliver results.  It’s time to start Delivering Happiness.

P.S. I received a free copy of the book so that I could read it and write an honest review about it in time for the launch date.  I received my free copy on nothing but the promise that I would write an honest review, and, all I received was the free book.  Other than my own integrity, I had no compelling reason to keep my promise.  I didn’t have to read the book, or write a review, or even write a positive review.  In fact, I could just as easily have written a review (irrespective of whether or not I’d read it) trashing the book — if it were trash.  But it’s not.  I have received plenty of free books to review and even requests to write forewords, summaries, afterwards, etc.  I have written (and had published) unflattering reviews (not something I relish) and I’ve also chosen not to write a review or contribute to a work when, as in the case of reviews, there was little nice to say, or in the case of contributions, I didn’t want to associate with the work.  All this is just to say: this is a very honest, unencumbered review.  There are no strings attached in any way for having written it.  Go read Delivering Happiness.  You’ll be glad you did.

P.P.S.  There’s also a Tweeter (@dhbook) to follow, and a community to join, and a Facebook crowd to like.  If this is your thing, I encourage you do so.

Truly Agile CMMI

Thursday, May 27th, 2010

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.