OK, OK, so it’s Mothers’ Day in the US… but we all miss out on family matters all the time for things far less awesome than this.

Lean Camp New England is a one day open space event led by Jim Benson, author of Personal Kanban. It is an opportunity to share and learn about Lean and Kanban in software development, IT operations and services, and other knowledge work fields.

Lean Camp New England is an all day event at the World Trade Center Boston, on May 13th (Sunday).
Registration is open now at a cost of $300 – catering is included.
Register at http://lssc12.leanssc.org/.

Boston is the center of gravity for lean thinking in the US. However, much of that thinking has been in fields outside of IT and Software and Systems Engineering/Development.

If you live in New England, or people you know live in New England, and are interested in getting up-to-speed among the leading thinkers and practitioners in Lean in IT and Software and Systems Engineering/Development, I highly encourage you and them to register for Lean Camp New England.

This is a rare opportunity to enjoy a regional 1-day open space / unconference in conjunction with a large international conference, Lean Software & Systems 2012 – as a result a significant number of international experts will be present and participating.

Where else can you get direct coaching from the experts for only $300?

For more than the last 10 years I’ve been thinking a lot about CMMI.  Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation.  I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks.  And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle.  I wish I were.  And, this is what’s both frightening and sad.  I’m merely talking about the relationship between capacity and demand.  For that matter, I’m not even worried much about demand, which is another matter.  I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work.  Throughput, for instance.  According to others, it’s the wherewithal to do the work.  Either way, too many operations don’t know what their capacity is. 

What does it actually take to get work done?  And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees].  This is an "out-of-tolerance" condition.  It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends.  Furthermore, it is risky to do so.  One client said he couldn’t be away from the office for 5 minutes before product would stop shipping.  Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation! 

What’s worse is the extra time he and his team put in is entirely unaccounted-for.  His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out.  The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation.  But a better equation to work with is work worked-on = work completed.  The key mistakes is the assumption that started = in-work.  That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months.  Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility.  And, to put it plainly, by "programmatic" I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want. 

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation.  In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize.  Over time, they’ve found that their Build*Capitalize approach is tough to Sustain.  Try that they might, whether it’s CMMI or something else, they’re looking to "fix" the equation on the "Sustain" side.  The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the "Sustain", it’s that their approach to Capitalizing on what they Built is no longer Sustainable.  What needs to change is on the Build side.  Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose "build" is broken is putting the cart before the horse.  While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the "build" side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side.  If CMMI is to be truly about improving the processes of the operation in a "sustaining" sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity.  Because unless it knows its capacity, it doesn’t really know what’s going on.

For more than the last 10 years I’ve been thinking a lot about CMMI. Many of these thoughts have been ruminating on the ideas of how to incorporate CMMI in ways that add value, demonstrate effectiveness, and don’t disrupt the operation. I’ve even opined much in this blog (in too many ways) on the need to know what your processes are before you can use CMMI to improve them, and that for many operations, CMMI isn’t even appropriate.

A few recent discussions and experiences put a particularly fine point on the extent to which CMMI is really the ‘cart before the horse’ when applied within an operation that has yet to clearly discern its process, and here’s why:

Most operations I’ve encountered are not ready to use CMMI because they are unclear on exactly how they make money.

Obviously, I’m not talking about the accounting process of billing out invoices and depositing checks. And, I’m not even talking about the voodoo around figuring out how to ensure that internal costs (salaries, equipment, etc.) are less than what they charge clients for the work they do.

So, I must be talking about something more subtle. I wish I were. And, this is what’s both frightening and sad. I’m merely talking about the relationship between capacity and demand. For that matter, I’m not even worried much about demand, which is another matter. I’m mostly talking about capacity.

What is capacity?

According to some, capacity is a measure of volume of work. Throughput, for instance. According to others, it’s the wherewithal to do the work. Either way, too many operations don’t know what their capacity is.

What does it actually take to get work done? And, along with that, can it be reasonably expected of the operation to reliably and predictably continue to run how it runs (not knowing exactly how it runs) and to have any right to greater-than-zero confidence that they will continue to run as it does?

For one thing, many operations run outside of reasonable tolerances. In particular, people put in many many hours of unpaid over-time [in the US this is common for salaried employees]. This is an “out-of-tolerance” condition. It is unreasonable to expect an operation’s greatest source of working knowledge to continue to work nights and weekends. Furthermore, it is risky to do so. One client said he couldn’t be away from the office for 5 minutes before product would stop shipping. Eventually he will get married or his wife will have a child, or, heaven-forbid, he may take vacation!

What’s worse is the extra time he and his team put in is entirely unaccounted-for. His employer merely estimates, contracts, and bills enough to cover his and the team’s salaries, not what it actually takes to get work done.

Another reason true capacity is obscured is because more work going into the operation than there’s product (or services) coming out. The most common cause of this is the misperception that work started = work completed, but this is an incomplete equation. But a better equation to work with is work worked-on = work completed. The key mistakes is the assumption that started = in-work. That’s true for maybe 50% of the actual started work (often less).

This next reason for the lack of insight into true capacity (or capability, really) is that so many operations don’t account (either in their estimates — which sort-of makes sense — or in their capture of time-spent — which is unforgivable) for the time to correct defects, time to perform rework, time for paying-down technical debt, or time and effort to tracking-down the causes of defects and rework to avoid defects, rework, and technical debt in the first place!

I’ll end with one of the toughest, most sensitive observations of the last few months. Some of my best clients (from the perspective of having their act together) have strong confidence in functional competence and, admittedly, weaker confidence in their programmatic credibility. And, to put it plainly, by “programmatic” I mean their ability to have the same confidence in the rationale for their estimates and plans as they have in their ability to produce what their clients want.

In these operations, I’ve found fundamental disconnects between how work is estimated and why clients should trust the technical competence of the operation. In other words, they build trust with their prospects and clients on their ability to do the work and build the products, but in order to get the work in the first place they have to use a lot of hand-waving and breath-holding when it comes to their estimates.

A more-or-less summary way to describe all of this is as follows:

Most operations have Built a way of working that they’ve managed to Capitalize. Over time, they’ve found that their Build*Capitalize approach is tough to Sustain. Try that they might, whether it’s CMMI or something else, they’re looking to “fix” the equation on the “Sustain” side. The problem is that CMMI *does* operate on the Sustain side, but the problems with the operation aren’t in the “Sustain”, it’s that their approach to Capitalizing on what they Built is no longer Sustainable. What needs to change is on the Build side. Occasionally, there’s a need to revisit the Capitalize component, but most often it’s the Build that needs refactoring.

Hence, applying CMMI to an operation whose “build” is broken is putting the cart before the horse. While it’s possible to build CMMI practices into the operation’s way of working, this is an activity of the “build” side of the equation, the sort I noted above contrasting from applying CMMI to the sustain side. If CMMI is to be truly about improving the processes of the operation in a “sustaining” sort of way, and not defining them, the operation must understand what’s going on, and that means it must know its capacity. Because unless it knows its capacity, it doesn’t really know what’s going on.

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!

I learn so much from failure it’s hard to ignore the good that comes from it.

This week I parted company with a client long before their goals were reached.

Sadly, I knew from the start they would be a challenge and made the mistake of ignoring the warning signs.  Never again.  Honest!

This entry is as much for coaches and consultants as it is for teams, staff, management and leadership.

There are several tell-tale indicators of success and/or failure.  In our own ways and in their own contexts, experienced coaches and consultants know what these indicators are.  Well-rounded, experienced, and seasoned practitioners within companies know them too.  In fact, most people know them instinctively, somehow.  I can therefore safely say that whether it’s through experience or instinct, we all know many of the same indicators.  In fact, we can probably sum-up every indicator in one word: Attitude.

So, yes, Jeff Keller’s famous self-help book, "Attitude is Everything", applies as well.  In organizations, "attitude" is frequently interchangeable or encompassed by company "culture".  And yes, attitude is a derivative of culture.  But sometimes culture is harder to pinpoint than attitudes.  Attitude shows up in your interactions with the company from the very start of your prospecting dance.

Here are some attitudes you may encounter and whether or not they spell greater odds of success or failure:

Failure-prone attitudes:

• Hassling about price/cost/time but expecting the same scope and performance outcomes.
• Focusing on deadlines and schedules instead of real results.
• Not owning the work and expecting off-site outsiders to invent working approaches.
• Shallow goals that aren’t S.M.A.R.T.
• Mistaking a task for an outcome or goal.
• Ignoring, denying, and filtering information that indicates problems.
• Poor communication (which often starts with poor listening skills).
• No allocation of explicit time and/or resources to make improvements.
• Failing to recognize the importance of the right people in the right roles for the right reasons.
• Delivering materials for review with no lead-time for turn-around.
• Persisting in propagating bureaucratic policies despite the obvious lack of value-add.
• Executives who are mostly (if not exclusively) involved in decisions involving budgets but not in making changes.
• Repeatedly using external influences as excuses to not make important changes.
• Assuming a victimization attitude instead of owning up to their circumstances.
• Failure to learn and apply new ideas — even after being presented with the benefits of those ideas.
• Management by motivation 1.0 or 2.0

Success-leading attitudes:

• Focus on results not the cost of getting them.
• Clear, S.M.A.R.T. goals.
• Executive involvement and ownership of leading the changes.
• Respect and appreciation for everyone’s contribution and effort.
• Active concern for overtime, unplanned work, and defects.
• Accounting and planning for everything that takes time by everyone involved.
• Taking full ownership for all the work (irrespective of the “divisions of labor” as seen by the customers).
• Clear-eyed view of effort and not planning around "best case only" scenarios.
• Ability to appreciate the need for non-technical, non-managerial skills in the roles of leading change.
• Seeing beyond the surface: A desire to learn and understand the meaning behind the work, not just following the specific language of the work.
• Dealing with people as people and not numbers.

My best clients have always had direct, clear and unambiguous evidence of two things:

1. S.M.A.R.T. Goals, and
2. Executive involvement in making the changes happen — not just lip service and budget authorization.  This usually took the form of the top leader (or 1-step away) taking personal involvement in not just setting direction, but in working through the best way to make things happen with the people who will be most affected.  (What does NOT count is a “top” leader with a purely administrative role and no executive accountability or responsibility.)

In experiencing the failure with this client, I admit to learning about at least one critical oversight on my part (there were others but this one takes top spot).  As we were interviewing each other, I failed to interrogate the leaders of the company for specific improvement goals.  The only "goals" they came to me with was to make their processes "leaner" and to attain a CMMI Maturity Level 3 rating with leaner processes.  Which turned out to really mean little more than to replace their heavy-handed compliance-oriented approach with a set of processes more projects could comply with more easily.  Again, note that they were still about "compliance".

Despite claims to the contrary, I didn’t fully realize until well into the engagement that compliance was still their primary attitude — at least among the people who were charged with overseeing the process assets for the entire organization. 

During the engagement, I repeatedly worked to identify meaningful improvement goals that being "lean" could help them attain.  I then created a strategy that would bring them closer to these goals and presented it to the majority of the executives.

Despite wide agreement on the goals and the strategy, when it came to rolling out the necessary changes, it was met the same-old resistance to change and fears that I knew spelled doom.

Nonetheless, I had high hopes for this organization so I decided I would bring them around by modeling the behavior I was trying to help them see.  A few people caught on but, alas, not the people who held sway in the organization.  Our mutual falling-out began early when it became apparent that desire among the leadership to achieve a maturity rating without upsetting the apple cart was overshadowing the desire to actually reach the performance goals being a leaner organization would achieve.

Notwithstanding, there were other tell-tale signs from the list above that this organization didn’t have the attitude to make the changes necessary.  I won’t belabor you with the complete saga.  Instead, I’ll return to my point about this entry.
You as coaches, consultants, and staff can’t want to better than your leadership is prepared to be.  The signs are all around you.  Pay attention to the signs early.  You will save yourself a lot of time, heartache and frustration.  If you believe you don’t have enough experience to justify your powers of observation, then trust your instincts.  Is the organization defensive about their entrenched position on their circumstance?  Do they make excuses instead of setting goals?  Are the goals devoid of any real results? 

You don’t even have to go that far.  How are you treated as a person, as a professional, is about all you really need to know about whether or not there’s a hope that things can get better.  If you’re not appreciated, if your organization is willfully blind to the things that cause you grief, if you see signs that tell you the organization lacks "class", you don’t need 20 years of experience telling you you’re right to know you’re right.  This organization is doomed to mediocrity.  Is that the kind of organization you want to be associated with?

I don’t, and, I won’t ever be again.

Even organizations who sincerely want the benefits and improvement that comes with many well-established, well-respected practices may be undermining their own efforts.

By placing a premium on practices (agile/lean, CMMI, etc.) without the underlying values and principles, organizations risk becoming accidental level-chasers.

As an earlier post discussed, level-chasing is very deleterious and, frankly, stupid, but how and why would organizations find themselves doing so — accidentally?

They do it by focusing on practices and by putting practices in place without understanding the values and principles these practices are derived from.  In fact, these practices are merely examples of what can be manifested from the values and principles and don’t represent a complete concept of any one value or principle.  By worrying about practices (and often, the evidence from them), organizations fail to get the most out of the practices themselves, let alone the values and principles of the practices — which have much greater depth and utility.

Without getting into the details, it’s now a fairly well-accepted understanding that focusing on what you don’t want does not necessarily get you closer to what you do want.  In fact, it’s shown that focusing on what you don’t want will more likely lead you closer to exactly what you don’t want!  This translates precisely to what I see each year with many clients.  If you don’t want to change your practices in unnecessary ways, focusing on practices will pull you farther from what works best for you.  If you don’t want to generate artifacts for the sake of artifacts, focusing on which artifacts you do/don’t have will cause you to generate non-value-added artifacts.

At the center of this issue is that practices are just singular (or sets of) examples that typify a particular value or set of principles.  When an organization performs a practice without understanding the value and principles from which the practice evolves, they often don’t know how to respond when challenged with the need to change the practice.  They fear that changing the practice will negate something bigger, such as a CMMI rating.  The mere concern for such ratings is an obvious red flag, but it’s sometimes not because of a need for the rating as much as it is due to not understanding the role the practice in achieving that rating.

Here’s where a favored analogy works really well:

Anyone who’s learned to play an instrument (or a sport) knows the value of practicing.  Sometimes, we practice things that aren’t songs, per se, but are musical study pieces.  Sometimes we practice scales and progressions.  And yes, sometimes, we spend a lot of time practicing a specific piece.  But the practicing of one piece doesn’t land us to be masters of a piece we’ve never seen.  Practicing one piece helps us master that one piece but brings us no closer to mastering an entirely new piece.

However, what all forms of practice are, are examples of certain values and principles of playing music and learning to play an instrument.  It’s the value of practice (growing our capabilities, evolving our understanding, enhancing our dexterity, etc.) that we all appreciate.  With this appreciation we’re able to justify and enjoy the practice.  We don’t just practice one piece in hopes of being able to master all other pieces.  It’s the same as why we don’t just practice one play or one maneuver in sports as though learning this one thing will help us learn and master the other plays and maneuvers.  We practice and when things change, we change the practices.  When the specific application of what we’re doing changes, the practices change, but the values don’t change, and principles change very little (if at all). 

A few of the values that lead organizations to being able to both perform practices appropriately as well as being able to change them when needed and still see the benefits of the practices include commitment to TQM, lean, disciplined/deliberate review, communication, transparency, learning, solid engineering, solid service management, and clearly articulated, S.M.A.R.T. goals everyone can sign-up to support.

Arguing over whether or not your practices “comply” with CMMI, or to one of many flavors of agile or lean is the wrong argument, and, leads an organization to limited benefits.  It’s a fast path to being a level-chasing, pathological box-checker.  Avoid this path by understanding the values and principles of the practices.

This topic will be one I’ll spend much time these next several months speaking on in many venues.  Hope to see some of you at one!

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.

If you use CMMI for the ratings only you will be limiting your growth.  CMMI can only put you on a trajectory for growth but can’t determine what that trajectory should be.  For that, executives must identify business goals they want to aspire to and then you can use CMMI to help achieve them.  In particular, goals in terms of time to market, cycle time, product or service quality, efficiency, customer delight, response time… anything that equates with operational excellence and profit.  Without these business goals and the measures to determine how well you’re moving towards them, CMMI will just frustrate your people and waste your money.

If you don’t value the idea of raising profits by lowering operational cost, then don’t bother with CMMI.  If all you want is a rating, then you will never see any benefits from CMMI.  Either you establish business growth goals, or CMMI will just eat away at your business.  If getting leaner isn’t appealing, stay away from CMMI.

It makes me sick every time I hear a company complain how much it costs to maintain their CMMI “rating”.  It pains me to hear of companies with recent ratings who are still habitually over budget and behind schedule, and not getting better.  I’m bewildered by companies afraid to make changes to the operations for fear of “losing” their ratings.  What these real-life I’m-not-making-this-up scenarios all have in common is that every one of these situations shares the attribute of using CMMI for the ratings and not the business value of growth.

I’ll take some blame for that on behalf of the other hundreds of consultants and appraisers out there.  Sure, I can’t prevent executives from being short-sighted and ADHD, but I can do my part for allowing executives to go forth with misuse of CMMI knowing that they will ultimately fail to see any benefits.  Is that how I personally work?  Of course not, but that is how too many other consultants and appraisers work, so on their behalf, I’ll fall on the sword.  Shame on us for allowing companies to use CMMI in stupid ways when we know it’s a bad idea. 

On the other hand, what can we consultants and appraisers do when executives willingly take the “ratings over growth” route?  When executives are not willing to stand up for what’s best for the business?  When the executives are not motivated to pursue operational excellence?  At the same time, we’ve all been using the wrong language with CMMI.  Who the heck wants to hear about “process improvement”?!?  That’s a lot like wanting to hear “you need to go on a diet and get more exercise”.  Who wants that?

What executives need to hear and see is that CMMI for the ratings limits growth and is worthless but CMMI in support of increasing profits is priceless.

Use CMMI for a rating only and your business will stop its growth right where the rating starts.

I’ve been given several opportunities lately to be thinking about the relationship among product development, agility, and services.  In a recent conversation regarding (of all things) how to sample work for artifacts in a CMMI for Services appraisal, it became clear that taking a services view of development actually makes a lot of things more obvious when it comes to where and how to make performance improvements.

Furthermore, the idea that product development can be modeled as the organization of particular services – such that the culmination of all the services results in a product – not only enhances the understanding and performance of the development flow, but it also creates a strong affinity to agile management and development values, principles and practices.  In fact, a service-oriented development flow is how Kanban views and manages development, and even shares many parallels with traditional services such as “cumulative” work and flow.  And, seeing development as a flow of services simplifies if not eliminates the endless catch-22 of dealing with planning, resource allocation and work volume.

In the video, I was at the tail end of a week-long exposure to a very demanding product development and services delivery context: aboard a pleasure cruise ship.  At this stage of our family’s development, pleasure cruising has emerged as our vacation of choice so this was my sixth cruise in over 10 years.  The first three cruises were with three different cruise line companies and the most recent three were with the same line.  What struck me most about the ship’s (and this cruise company’s) operations were its flexibility and responsiveness to change.

Despite many constraints, within those constraints the ship was autonomous, and, the various departments within the ship had degrees of autonomy.  Beyond autonomy, there were clear components run centrally and just as clearly there were components that were decentralized.  But it all worked as a single service: the ship.  Within nearly every service were products to be developed, whether produced from scratch or recreated afresh over and over again.  Yet again, the massive, highly complex service system operated in an agile way by nearly any measure of ‘agility’ in nearly every facet of how it ran.

A few days after my return from the ship I had the opportunity to teach Introduction to CMMI.  This offering was to one of my clients and a guest.  All participants were sharp and involved – which isn’t always the case with such classes.  The class was special in that I was experimenting with new course material for the SEI in which I was delivering content from the CMMI for Development constellation following content from the CMMI for Services constellation.  This experience reinforced for me and exposed the participants to the strong relationship between Services and Development, the strong benefits of viewing development as a service (from both operational and improvement perspectives), and, helped my client (who uses Scrum, Kanban, and traditional development in various parts throughout the company) see common threads to help improve performance irrespective of how they approach management and development.

The learning for agile and CMMI cooperation may very well be found in services.  Think about it.  Now, class, discuss.