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?

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!

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.

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.

OK people… if your approach to CMMI sounds like this Dilbert cartoon, maybe it’s time to face reality.  You can’t do it without proper training (whether in the form of traditional courses, or the knowledge-transfer mechanisms of mentoring, coaching, etc.)

In other words, if you’re trying to use CMMI and you’re not getting smart about what it is, Dilbert just called you out as a moron.

To pursue CMMI and/or to reap the benefits of agile requires more than just desire at the working level.  It takes:

• honesty
• learning
• transparency
• respect
• support
• trust
• patience
• commitment (to excellence)

Not just from people who will feel the changes most immediately but from the top-most person in the company on down to those people whose work support the people who will feel the changes most.

If you have an executive who declares: we want “maturity level __” by such-and-so date, and doesn’t themselves bother to take the time to understand what that means, you don’t have what it takes.

If you have an executive who declares: we want “to be more agile” but doesn’t allow developers to organize their workspace or their time, you don’t have what it takes.

If you have an executive who doesn’t care how negatively a drastic poorly considered change will impact the developers, you don’t have what it takes.

If you have an executive who expects everyone but themselves to change or expects that hiring an outsider can eliminate the hard work needed to move from the present situation to the desired state, you don’t have what it takes.

Might I recommend this course for getting to know CMMI, at least.  It can be attended in person or on line.  Live.

DISCLAIMER:  This information is being provided as a service to anyone interested in taking Introduction to CMMI but can’t find a time or place to do so with the SEI or other providers.  I do not profit from making this information available.

A client of mine in Cedar Rapids, Iowa is hosting Introduction to CMMI (for development) on 8-10 September, next month.

They’d like to make the class more robust by having more people in it.  The number of students will be limited to under 12, so it will still be a very intimate class with plenty of opportunity to get into specific questions and implementation issues.  A brief overview of CMMI-ACQ and CMMI-SVC will also be included.

In addition to the class materials and the "blue book", all participants will receive a zippered folio pad, pen, highlighter, CMMI poster, quick reference card, and a tote bag.  Breakfast and lunch are also included.

As I understand it, folks in that part of the country are willing to drive 5 hours or more to get around.  For folks like me, that’s crazy-talk! 

If you know of people who are interested in taking Introduction to CMMI with an excellent instructor, great location and for a very reasonable cost, let me know by email (link on right side-bar) and I’ll give you the cost and other details.

… Expect to learn all the time, and you will learn.

I’m working with a great client in Connecticut.  A referral thanks to Bob Lewis.

First off, over coffee Bob unknowingly gave me a new set of metaphors for a topic he admits to having little understanding of: CMMI.

To spare you the details of what he said and how I processed it, please allow me to simply explain the gist.  In CMMI there are lots and lots of things called "practices".

Many people interpret these practices as though they are processes, or worse even, procedures, and they execute the practices mechanically.  Yes, that’s usually because these same people either (a) are chasing a maturity level rating, or (b) simply don’t understand how to use the model to reap the greatest benefit, or often, (c) both a & b.

Here’s how to actually and properly use the practices in CMMI:

They are underlying motivations.

When you think of what doctors, lawyers, athletes and performers do, they practice their art.  And it’s a practice because they’re constantly applying, learning, adjusting, and responding to the non-ideal and unpredictable conditions presented to them in real-time.  If they were simply following procedures every time, they’d fail most of the time.  Yet, they practice, practice, practice, so that when it comes time to perform the practice they aren’t worried about following pre-determined procedures because they must be able to respond to what’s thrown at them in reality.  The procedures assume a pre-determined situation and the responses to procedures are ideal to those situations.  What they’re exactly doing in real-time comes from their practice, but doesn’t necessarily look exactly like what they did last time.

Procedures are good when all the inputs are controllable.  Processes help know what major transformations an object or an idea must go through to become an outcome.  Processes generally follow an expected sequence, but what happens inside the process should have enough flexibility to be rearranged to meet the needs of or to normalize the input conditions.  What the procedures must do, however, is respond to reality.  The way in which procedures inside a process respond to reality to become rearranged or redefined based on the principles and motivations of practices; which are not necessarily even explicit.  They’re "just there".

For example, at the process level, a doctor goes through several steps prior to, during and after performing surgery, (e.g., consult, exam, test, analysis, advise, prepare, communicate, operate/investigate, clean/close, protect, follow-up…). Each of these sub-processes to the process may have certain procedures, but each of those procedures is contained within at least one practice.  The practice may not even be written, or formal, but they’re certainly part of what the doctor is trained to do based on principles and motivation.  These principles and motivations are taught and refined over time, with practice.  And true, some practices can be beyond the capability and/or maturity of some people.

It’s no wonder when an organization’s true underlying motivation is the shallow ceremonial decoration of a rating that their results are equally shallow despite the time, energy and money that went into the production effort to pull off ceremonial decorations. (Think: big, gaudy, wedding where everyone knows the couple won’t last.)

While learning this lesson, Bob pointed out that what he and I do for a living are, in fact, practices (i.e., consulting practices) and the next morning I find myself before a cozy crowd of client staff and despite having thought through much of how things would go, I still felt like I was winging most of it.  In reality, in real-time, I *was* winging it.  I was responding to the reality, but was never out of my element because I was still…. practicing.  Following the basic principles and motivations to achieve an outcome.

So it all worked out and everyone was pleased.  We made a lot of progress and then I learned the next lesson in this 24 hour period of time: It’s really a lot of fun to actually be on the sharp end of the stick once in a while… actively blending Scrum and the immediately useful bits of CMMI.  The real lesson, though, was in gaining re-enforcing validation as I witnessed this organization actively absorb and propose process ideas.  There was no push-back.  Quite the opposite.  Processes were being embraced as one of the things that would lead them towards success.  The alternative would be a slow dissolution of the company.

Once in a while it’s nice to really see just how effective blending good ideas can be when this process stuff is put into context of what must be done to succeed.  It just demonstrates again that too many organizations are using CMMI for the wrong reasons made worse by a lack of practice.