Archive for the ‘CMMI for Services’ Category

Agile is a Service: You May Be Improving the Wrong Things

Sunday, October 9th, 2011

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.

[NOTE: For the remainder of this post, I’m going to assume the development operation actually knows its technology and knows what real engineering development looks like.  This is a big assumption, because we all know that there are development operations a-plenty whose technical and engineering acumen leave much to be desired.]

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

Services and Agility

Tuesday, September 21st, 2010

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. ;-)

Prague Report: SEPG-Europe 2009

Saturday, June 13th, 2009

Despite half the attendance from 2008, the sessions were of very high imagequality and the size of crowd really facilitated an intimate setting to network, eat more than one meal with old and new friends and to have serious conversations about process improvement and the direction of SEI and its Partner network.

While it’s not an entirely fresh thought, it really hit home for me the extent to which conferences — and other concentrated spans of time, in general — have the ability to shake loose new ideas. This conference, sometimes (I admit) unlike other events, I really spent an enormous amount of time and energy reflecting on all-things-process including my own work and company, collaborations, CMMI and other SEI products, and the SEI itself at a strategic level.

It’s clear that when you spend that much time on learning, studying and inspection of ideas, the constant barrage of collisions and connections, that all sorts of (typically good) things can come of it. Really, I suspect that these not-so-obvious benefits all-too-often go under-appreciated, and under-utilized as secondary and tertiary returns of getting the most from attending conferences and of sending people to conferences. For my time (and money), these events have the potential to be far more value than mere training and seminars. And, this year’s, SEPG-Europe really made me appreciate that.

image The only event on Monday was a workshop on CMMI for Services which included several spirited discussions about model content and applications. An idea-generating session was conducted for how to address qualifications, continuing education, and related credentialing, for qualifying Partners to teach a new training class I’m helping develop in my role as an SEI Visiting Scientist. This discussion warmed up to even higher heart rates. (In a good way.)

Tuesday was the official tutorials day. My CMMI Crash Course could have gone better — I was dreadfully under the weather from something I ate the night before. I also had it confirmed for me that the European crowd of novices is very different on many levels than American, British and other cultures. I couldn’t get people to participate even with (mock) threats and jokes. They simply wouldn’t open up. While they would ask questions at times, if I asked a question, they’d wait for me to answer it — even when prompted them to answer. It came across as though one Danish student had more courage and better answers than the room full of working professionals.

While having the best of intentions to attend afternoon tutorials, I found myself back in bed, skipping lunch and dinner and only emerging once or twice to grab something to drink to stave off dehydration.

The exhibit area opened Tuesday evening, and I showed up with my shirt hanging out, no jacket or socks and looking very much like someone dragged me outside in the rain, hastily dried me off, then stuffed me into well-worn clothes. But, by the evening I was feeling better. Good enough to go down to the adjacent mall to buy 2 bottles of PowerAde. Once of which didn’t even survive to see me emerge back out from the mall.

Wednesday, Thursday and Friday were the main conference days. Each one filled with excellent content. (You can download highlights here.) A former client of mine, Kevin Williams started my Wednesday day off with superb content on his (former) company’s CMMI journey complete with metrics, examples, and lessons learned. It was a genuinely rich and rewarding example for how small and agile organizations can stay agile, use CMMI to benefit their work and get a desired rating. Kevin reported that despite having left the company and not having been replaced, the processes put in place under his leadership are still in use.

His session would have been better attended (by more people who really needed the information) had it not been for a slight oversight that left the word “Agile” out of his presentation and abstract. As a result, Kevin’s 40-minute slot was opposite the start of a half-day tutorial on agile and CMMI from Tim Kasse who really put agile and CMMI under the engineering microscope — at least while I sat in on the 2nd half of it, so I assume the earlier half was as hard-hitting.

It was hard to tear myself away from the excellent networkinClock tower after dusk ~9pmg to get back into sessions throughout the week. Then, once I got back inside, there were other obligations keeping me from staying. For example, to go “play expert” for an “Ask the Experts” break-out, I had to bail out half way through Michael West’s insightful work and thoughtful mini-tutorial (complete with hands-on exercises) on process design and communication.

The first keynote speakers started Thursday, but afterwards, the highlight of my Thursday sessions was John Hamilton’s talk on complex process concepts for absolute beginners. He was highly energetic, entertaining, and very crammed full of excellent advice. I’m “borrowing” several turns of phrase from him — which is only fair considering he borrowed a number of ideas (and words) from me. Fair trade. (Be flattered, John, I am!) ((John actually asked me about his use of the ideas at his company’s recent conference — where I also spoke.)) I believe it’s from John that I tweeted about where the real improvement begins.

Friday. Ah, Friday. The way Friday got started was surely a sign of good tidings. Tony Devlin’s keynote was simply inspiring. My tweets (also) from it don’t even tell the half of it. Talk about true maturity. Do they *get* this stuff or what?! I can’t even bring myself to write about it out of fear of not having time to sleep tonight once I start. I expressed my thanks afterwards and expressed a request for learning from them and extended an open offer to answer questions from my experience in return. He graciously provided me with his email address and said he’d bare all. Then to have had lunch with him was a real treat. I was already eating with 2 SEI personnel (including Mike Philips the program manager for CMMI), and with one open space, Tony asked to join in. After making a fool of myself over light banter — in which I forgot an actor’s name, thereby forgetting his nationality, and only remembering that he portrayed an Irishman in a movie, causing me to think he was Irish, only to be admonished for confusing Irishmen with Scots when someone recalled the actor for me — we got back to discussing his experience and solidified our intent to exchange information.

Friday was no where nearly done. A session on multi-model collaboration by Kobi Vider-Picker was incredibly well-researched and his audience was full and attentive. He basically laid-out how well the CMMI suite can handle dozens of standards, guides, regulations, etc. I understand he doesn’t need to sleep or eat much. It must be how he finds the time between all his work to do such thorough research. The next session was by Malte Foegen, the tweet from that session set off a chain-reaction of re-tweets. Probably my longest ever.

Lastly, my mini-tutorial based on the SEI Technical Note probably had about a third of the entire attendee roster. Of course, by 4pm on Friday, nearly the entire roster had already started out for the airport. By this point, people were more open to volunteering discussion. Nonetheless, I was struck by how deeply ingrained certain ideas about CMMI (and Agile) have been etched. Despite months of promoting the subject since the publication (years prior to that online); despite the availability of the Crash Course, and other sessions from other events, despite all the presentations throughout this and other SEPG events, and for many, having sat through the Crash Course just days before . . . some misperceptions about CMMI and Agile (such as how certain practices “must” be done, or what constitutes “evidence”, or that process definition is process “restriction”) just are almost too hard to give up.

There is work ahead still.

I’m on it.