Archive for the ‘Improvement’ Category

Performance and Change

Sunday, August 7th, 2011

Over the past weeks I’ve come in touch with several companies with the same exact challenge.  Though, to be sure, it’s nothing new.  I encounter this challenge several times each year.  Perhaps, even following Pareto’s principle, 80% (or more) of the companies coming to me for improved processes have a variant of a form of distress that accounts for no more than 20% (or less) of the possible modes of distress.

In particular, the challenges are variants of a very basic problem: they want things to change but don’t have an objective performance capability to aspire towards.  Put another way, they can’t articulate what it is that their operation cannot currently accomplish that they’d like their operation to be able to do once the changes are put in place.

I’ve mentioned “SMART” objectives before.  Here’s another application of those same objectives, only now, they show up at a higher level within the organization. 

Choose the right objectives.

Executives of the organization often confuse “SMART” objectives with “fuzzy” objectives.  By “fuzzy” I mean objectives that appear to be “SMART” but aren’t, and, the fuzziness obscures the situation so as to over-render the truly uninspiring nature of the objectives as being substantial accomplishments.  In fact, fuzzy objectives are not actually objective (lacking a solid way to measure accomplishment), or, are easily “gamed” (data or circumstances can be manipulated), or, are very deep within their comfort zone – or the opposite – are ridiculously unreachable (achievement is too easily attained or excused for not attaining), or, are indicators of task completion rather than indicators of actual outcome changes (don’t actually achieve anything but give the appearance of making progress), or, aren’t tied to actual increased capabilities/performance (don’t cause anything to change that anyone cares about), or, are dubious achievements that can be accomplished by simply “rowing faster” (working harder by working longer hours or assuming too much risk or technical/managerial debt), and so on. 

These same “fuzzy” objectives are frequently couched in deceptively goal-esque achievements such as achieving a CMMI rating, or “getting more agile”, or getting ISO 9000 registered.  What I noticed among the recent crop of companies with these issues is that they shared a particular set of attributes.  They were after “improvements” but didn’t know what they wanted these “improvements” to enable them to do in the future that their current operation was preventing them from accomplishing.  Sure, as in the case of CMMI, achieving the “objective” of a rating would enable the company to bid on work they currently can’t bid on, but that’s a problem addressed in two separate posts (here and here) from a while ago.

Digging a little further, I uncovered a more deeply-seated challenge for these same companies.  In each case, they could not articulate what they actually wanted to be when they “grow up”.  Closely related to not being able to explain how they wanted to be able to perform that their current operation precluded them from performing, they also couldn’t say whether they wanted their company to be leaders in:

  • product innovation,
  • operational excellence, or
  • customer intimacy.

According to Michael Treacy and Fred Wiersema, in The Discipline of Market Leaders, every company must decide the ordering of the above three values and how to organize and run the company to pursue the value they’ve chosen as first, followed by the second, etc.  Furthermore, and most seriously, leaders in the companies I visited were having serious issues.  Sometimes in more than one area: delivery, quality, scaling, proposal wins, proposal volume, cost pressure, and so on.  In none of the distressed companies were they looking at the performance capabilities of their operation.  And, in none of the companies did they have metrics that gave them insight into the performance of their operation or helped them make decisions about what to change or how.  In other words, they weren’t connecting their challenges to their lack of performance to the role their operational system of processes plays in that performance.

HPO_Cover_smOne thing that could help these companies climb out of the mud they’re in would be to simply and clearly define how it is they’d like to be able to perform that their current operations don’t facilitate, and, to define this capability in terms that represent an actual shift in how the operation functions.  Changes for improved performance is not about adding more work, adding more bureaucracy, or making people work harder.  Often, “working smarter” is easy to say but lacks substance.  “Working smarter” actually shows up as changes in the operational and managerial systems that carry out the performance of the operation.  A company that wants to perform better doesn’t need to add more work, or crack the whip louder, it needs to change how its operation runs.

More about this is in my upcoming book, High Performance Operations, available now for pre-order and due out at the start of October 2011 or earlier.

Lean Software and System Conference

Thursday, March 17th, 2011

I’m speaking @ the Lean Software and Systems Conference 2011.

The program is amazing!

I highly encourage attendance.

There’s an entire day in cooperation with the SEI with 3 unique tracks on it including a track on CMMI and Multi-Modal Processes (which I’m chairing).

Take a look at my talk… it’s from my upcoming book: High Performance Operations.

Register quickly and make your hotel reservations! Block rooms are nearly gone!

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.