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?

Want fast, easy CMMI ratings?  Even high maturity?

First, implement lean, Goldratt’s TOC, Deming’s ideas, Kanban, and other related concepts, then get busy with CMMI.

What you may not know is that lean is easier, faster, and generates better performance results sooner than CMMI.

Lean improves delivery issues sooner than process improvement alone.  Improved deliveries improves revenues, stabilizes cash flow, increases margin, makes customers happier and results in more sales.

In other words, lean means better flow and better flow means better business.

CMMI is great, but is often attempted as a first line of offense to issues it’s not meant to deal with.  CMMI is meant to improve flow, not define it, and, lean helps define flow.
(Yes, I know I said "theory of constraints" twice.)

Assuming there are unfulfilled orders in the sales pipeline, lack of revenue is due to lack of flow.  Typically, this is due more to what’s in the flow, how much is in it, and the clarity and cleanliness of how the operation’s flow is aligned.  Using CMMI to "fix" issues with flow is like using the Brownian motion of steeping tea to power a random-number generator.  It’s just too much too soon.  Process issues are themselves symptoms of flow issues.

Deal with the symptoms first.  Then, tackle the processes.

Two events to put on your radar:

Lean Software and Systems Conference: Boston, 13-18 May (Lean Camp & Lean Action Kitchen, Sunday, Conference Monday-Wednesday, and Tutorials Thursday & Friday).  I’m helping to organize and speaking at the conference, and running a tutorial on this topic on Thursday.

Kanban Change Agent Masterclass: Miami, 23-25 May.  I’ll be participating as a special guest to demonstrate how Kanban helps achieve CMMI ratings, including High Maturity.

So much about software development (in particular, and product development in general) as a business has less to do with technology than it has to do with keeping customers happy.  What do customers really care about?  While they say they want their product on time, on budget and doing what they asked of it to do, most of the time, managing their expectations has little to do with time, cost, features, functions, or quality.  What they experience is more about how the developer treats them as a customer.  In other words, what they perceive as the developer’s business as a service is what customers react to.

Of course, customers aren’t typically happy when the product is late, doesn’t do what they need it to do, and/or costs more than they were expecting to pay – scope creep notwithstanding.  Be that as it may, agile development and management practices recognize the importance of customer involvement (and all stakeholders, in general).  In fact, while the “traditional” development and management world has long espoused the importance of an integrated team for product and process development, it’s the agile development and management movement that actually made it work more smoothly with more regularity.

(Before anyone from the “traditional” development camp jumps down my throat, keep in mind: I came from the traditional camp first and saw attempts at IPPD and saw how difficult it was to get it going, keep it working, and eliminate the competition and other organizational stress that IPPD continues to experience in the traditional market.  And, I’m also not saying it doesn’t work in traditional settings, just that it worked much better, much faster, and with much more regularity in the agile settings.)

From the beginning, agile practices understood the importance of the customer and of being a service to the customer.  Kanban (more recently) even refers to different types of work as “classes of service”.  In fact, if we look at the most common pains in development work (e.g., staffing, time, agreement on priorities and expectations), we see that it’s seldom technology or engineering issues.  They’re issues more aligned with the developers’ abilities to provide their services.

Let’s now look at another importance facet of all development, agile notwithstanding.  Much of it happens after the initial product is released!  Once the product is released, there is precious little actual development going on.  The ongoing support of the product includes enhancements and other updates, but very little of that work requires any engineering!  Furthermore, what is worked-on comes in through a flow of requests, fixes, and other (very-often unrelated) tasks. 

After a product has been released, the operation of a development shop resembles a high-end restaurant far more closely than it appears as a production floor.  Once the menu has been “developed”, from that point forward, patrons merely ask for items from the menu and for modifications to items on the menu.  Even were there to be a “special order” of something not at all on the menu, the amount of “development” necessary to "serve” it is minimal.  And, when something truly off-the-wall is requested, the chef knows enough to respond with an appropriately apologetic, “Sorry, we can’t make that for you right now.  Please let us know in advance and we’d be happy to work something up for you.”  At which point, they would set about developing the new product.

Meanwhile, the vast majority of the work is actually just plugging away at the service.  In the service context, development is often not the majority of the work.  In that context, engineering plays an important role much less often than the ability to deliver services, manage transition of services, ensure continuity of service, handle incidents, manage resources, and so on.

What does this mean for agile teams, and, what does this have to do with CMMI?

Well, maybe much of the perceived incompatibility between CMMI (for Development) and agile practices are not due to incompatibilities in CMMI and agile, but incompatibilities in the business of agile and the improvement of development.  In other words, maybe the perceived incompatibilities between CMMI and agile are because CMMI for Development (CMMI-DEV) is meant to improve development and many agile teams aren’t doing as much development as they are providing a service.  Perhaps it’s just that the business models presumed by the two approaches are not aimed at making progress in the same way.

When agile teams are doing actual development, CMMI-DEV should work well and can help improve their development activities.  But, agile teams are often not doing development as much as they are providing a service.  They establish themselves and operate as service providers.  Most of the agile approaches to development are far more aptly modeled as services.

CMMI for Services defines services as follows*:

• A product that is intangible and non-storable.
• Services are delivered through the use of service systems that have been designed to satisfy service requirements.
• Many service providers deliver combinations of services and goods. A single service system can deliver both types of products.
• Services may be delivered through combinations of manual and automated processes.

*Glossary CMMI® for Services, Version 1.3, CMMI-SVC, V1.3, CMU/SEI-2010-TR-034

Many requests made of many agile teams have more to do with supporting the product than developing a product.  While the product is still under development, then, by all means, CMMI for Development is apropos.  But after the initial development (where more product-oriented money is spent), the development is hard to see and harder to pin down.

Maybe, improving development is not the right thing to develop.  Perhaps agile teams could look at how they handle “development as a service” for their improvement targets.  Maybe CMMI for Services is a much better fit for agile teams. 

Could a switch from CMMI-DEV to CMMI-SVC benefit agile teams?  Could a switch from CMMI-DEV to CMMI-SVC make achieving CMMI ratings easier and more meaningful?

I believe the answer to both is a resounding: ABSOLUTELY!

ATTENTION AGILE TEAMS: You need a CMMI rating?  Look at CMMI for Services.  It might just make your lives easier and actually deliver more value right now!

[NOTE: I have an essay, Are Services Agile?, in this book on this topic.  Since you can “look inside” you might be able to read it without buying it.  Furthermore, the essay has been published online in some places.  You might be able to find it out there.]

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’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.

San Jose, CA.  Behold: Alistair Cockburn.  At the end of SEPG-Europe 2008, I was in a conversation with SEPG program chair, Dr. Caroline Graettinger.  We were discussing the theme of the 2009 series of SEPG conferences on Next Generation of process.  I immediately thought of and fired off an email to Alistair.  Intrigued, he said that he’s working on a very similar sounding set of ideas calling them, Software Development in the 21st Century, and accepted shortly thereafter.

This ideas are based in metaphors to help really manage software development the way software is really developed.  Cooperative Games, Craft, and Lean.  The details of this talk are on Alistair’s web site.

Alistair was poignant (despite mentioning me by name) and funny and fielded questions from the audience.  Kudos my friend.

Another Jim as Sr. Director for Software Quality, Jim Sartain, currently at Adobe, came next.  Previously at Intuit and before then HP.  Leading with the fact that TSP goes where he goes.  (See more later.)  He showed the same slide from yesterday’s Intuit presentation showing "most admired companies" where Intuit is #1 and Adobe is #2.

ANOTHER "quality" person with a REAL personality!  A clean-sweep for great SEPG speakers!  Too bad the economy kept more people from experiencing them!

Jim spoke about giving engineers the tools and work-life balance that can double their productivity and morale. Note: research this when there’s time.  And while I’m at it, research why it’s the commercial companies of the world who truly embrace quality culture and the government-oriented ones don’t.  (Never mind, that’s rhetorical.)

Wanna "get" how serious they are?  They frakking flew Watts Humphrey in to San Jose to launch TSP and brought as many engineers from around the world in to hear it.  But since their operations in India are so significant, they did it again in India!

Their results with TSP are beyond quality improvements, but work-life balance, team commitment, team self-direction, senior leadership buy-in (removing obstacles).  TSP provided a means of measuring the effort and using that data to negotiate better expectations.  (Both Alistair and Jim noted the importance of metrics to transparency and improvement.)  Jim also took questions including why to wrap TSP in Scrum.  Reasons: (1) Product owner, and (2) defined "done" at each iteration.  It turns out that TSP came to Adobe, not because of Jim bringing it rather because people at Adobe heard the great TSP stories coming from Intuit and "want sum’dat!"

A first for SEPG, was the inclusion of time between the morning’s keynotes and lunch for very user-group-esque "peer to peer" sessions.  Conference participants self-selected into table-top discussions driven by other attendees, not selected by the conference program.  In fact, attendees put up topics and volunteered to lead them — or put up topics in hopes of someone else showing up to lead and play subject-matter-expert.  To no-one’s surprise, David Anderson signed up for agile and lean discussions.  (David’s in the ruddy color left of center in the image.)  And, again, to no-one’s surprise, there were more people interested in this topic than room at any one table, so the conference logisticians moved the crowd to its own room where, as can be seen in the photo, numbered several dozen people.  Subsequent to this image, more arrived and were standing around the seated area.  One might sense a trend of growing interest in this population for the last few years whenever the terms "CMMI" and "Agile" are put together, eh?  As it turns out, of the several simultaneous peer-to-peer sessions, the two with the most participants were the Agile-related one and the TSP one.

(Well, super insider’s double-hush secret preview scoop of things to come: expect Agile, Lean, and TSP to start showing more prominently both at SEPG and throughout the work being done at SEI.)

David lead Achieving High Maturity with Kanban mini-tutorial.  His talk was mostly about the culture necessary to achieve high maturity and how Kanban can facilitate it that.  But describing it that way makes it sound like it was a commercial for Kanban.  It wasn’t.  It was about culture’s and measurement’s roles in maturity of development, productivity, quality and production management.  How the data drives the actions of the teams and these actions can be demonstrably linked to things that can actually be managed.  One way to summarize is in how he said, that "level 5" results are achievable by setting expectations of level 5 behavior as a matter of culture.  It’s telling that David’s session spanned 2 normal sessions.  People had the opportunity to leave mid-way and go to other sessions.  Despite other session opportunities, there was a net gain of attendees in David’s session.

After that, came me.

The CMMI Guide to the Perplexed.

Well-attended, many friendly faces and most people seemed to enjoy it.  Lots of positive feedback… of course, detractors seldom tell you to your face, do they!  You can get the presentation here.

San Jose, CA.  I’m at (no surprise) SEI’s annual big deal conference, SEPG-NA.  As might be expected, attendance is way down due to the economy.  SEI had to scale back a lot of the more splashy touches — no-frills tote bag, nixed VIP socials mixers bare bones staff.

I arrived in time to teach a CMMI-SVC Supplement course for the SEI on Sunday — scheduled to coincide with SEPG for the convenience of travel — that evening I shared conversation and a bottle of really nice California Merlot with Alistair Cockburn, Tami Zemel and Steve Masters.  Earlier in the day Alistair listened in on my class from the corridor and over cheese and fruit bluntly reported that the content made his ears bleed.  Unfortunately, he’s right.  Despite the mostly very positive feedback, there’s only so much charisma can do for certain SEI materials.

Alistair challenged me to explain CMMI to him in 5 minutes or less or he’d fall asleep.  I believe I succeeded.  He Tweeted as much at least.  As it turns out, not to either of our surprise, whether using agile terms or traditional terms, if you’re working to improve the experience and situation of "development", you have the same goals and face the same challenges.  With that settled we called it a night and met this morning over breakfast to joke about travel anecdotes and strategize our individual plans for the day.

With other obligations on my plate for this week, this morning I only sat in on half of a half-day tutorial this morning on the excellent topic of The Role of Organizational Culture in Process Improvement.  Rather than a bunch of finger-wagging (which, from other presenters, such a topic title might devolve into), anthropologists, Palma Buttles and Fred Valdez, and process improvement uber-guru Judah Mogilensky gave a very well-informed, thoroughly enjoyable, interactive and insightful tutorial on several very specific attributes of culture that affect how to introduce, address and implement process improvement, and the challenges faced by consultants, appraisers and users alike due to culture.  Concepts on the perception of time, surface or hidden emotion/expression, stated vs. rewarded values, and so on.  During this session, David Anderson arrived.  We commiserated over the registration statistics and what it may imply for other large-scale conferences like Agile2009.

To round-out the day’s sessions I attended Corey Ladas’ mini-tutorial, Launching a Kanban System for Software Engineering.  He put up a slide depicting a "waterfall" life cycle which included a "stabilization" phase-gate to which he said, "I don’t think I’m saying anything anyone doesn’t already know will fail."  Someone in the audience stopped him to ask (with incredulous tone in her voice), "Are you trying to say that this approach doesn’t work?"  <<Snicker.>>

After the tutorial, I headed off to the exhibit area for the "grand opening" of the exhibit hall.  As part of the fanfare, a troupe was hired to march around the exhibit hall in oriental dragon costumes accompanied by drums and cymbals.  It was festive and lively.  Though it would have been more appropriate had they been asked to start things off, lead everyone into the hall, do a circuit around the hall, then be done.  Instead, they continued to perform for a lot longer than needed.  In addition to causing traffic problems (which wasn’t really a huge issue), they made it hard to speak while nearby.  That was an oversight.  After a break, they returned to continue, only playing softer.  Still, their initial display was too long and they didn’t have to come back.  It wasn’t that it was bad, it was merely unnecessary.  As for the exhibit hall… so sad… so many fewer, and each booth featured fewer people.  The student posters, were a refreshing new feature this year.  I was impressed with their efforts, both in terms of research and commitment.  First person I ran into was from, of all places, UMBC.  Yup, home turf.

Afterwards, David Anderson and his gf joined several of us for a wind-down at the Marriott’s concierge lounge.  Well, as I should expect, my increased visibility within SEI and within the CMMI-oriented market has also resulted in never having to sit alone if I didn’t want to.  Even then, I didn’t always succeed in getting long stretches of time on my own.