A starting point for a discussion on marrying Agile methods and CMMI.Process In the Fabric
Posted by agilecmmi on Nov 21, 2011 in Evidence, SCAMPI, agile SCAMPI, artifacts, lead appraiser | Comments Off
Say you’re in a truly disciplined, lean and agile operation and your processes are so deeply ingrained in what you do that putting your finger on tangible evidence is a challenge, and not for lack of process. Just lack of being able to step back far enough from the canvas to see the whole picture. What do you when it comes to demonstrating your practices for a CMMI appraisal, for example?
Well… the best advice I can give companies in such situations is to work early and closely with a consultant and/or lead appraiser to elicit the best evidence for the appraisal long before the appraisal event itself is planned or carried out. It’s important to be clear about what the evidence is, and, you want the appraiser and the appraisal team on board with how the evidence will “show up”. This is not something you want to surprise anyone with come appraisal time.
Working early and closely with a lead appraiser will not only help everyone understand the context, and not only will it provide an opportunity to strengthen practices and identify operational risks, but it will give you a good idea about whether or not the lead appraiser has the wherewithal to think broadly about practices and to assemble the contextual picture for how practices would “show up” in the context of your operation.
Sadly, not all appraisers have this skill set. In fact, in my experience, the great majority do not have the skills to make contextually relevant model interpretation such that actual, naturally-occurring evidence from an operation can take its most natural form and still be recognized as implementation of CMMI practices. In my experience, most lead appraisers expect evidence to come in very specific shapes, sizes, and colors and they don’t recognize the evidence when it doesn’t meet their pre-conceived notions of what particular evidence should look like.
That being said, this does not give carte blanche for not having evidence. I’m not saying that the evidence isn’t there, I’m just saying that the evidence may not be what’s traditionally thought-of as evidence from larger or more traditional development operations.
Process evidence from operations whose processes are deeply ingrained can often show up as very clear, obvious artifacts. Especially from traditional development operations. However, in small, lean, and agile operations, the evidence can be much less obvious. It is a special skill set to be able to recognize the outputs of such operations as evidence of CMMI practices and organizations are served well to work with the lead appraiser early to determine whether or not their operation produces evidence as well as whether or not the appraiser can see more broadly than the evidence they’re used to seeing from traditional operations.
Since few organizations know how to pick a lead appraiser, perhaps this “litmus test” for a lead appraiser can serve to help them through the process. The alternative could be a disastrous paper-chase to create evidence on top of the evidence that’s already there.
Forget CMMI!
Posted by agilecmmi on Nov 15, 2011 in CMMI, CMMI for Services, Development, Engineering, Improvement, Level-Chasing, Maturity Level, Performance, ratings | Comments Off
This is probably the most important blog entry I’ve ever posted.
The video is the longest video I’ve ever posted on the blog, and for that reason, I’ll keep the text content to a minimum.
Here’s why you should watch the video: CMMI may be entirely wrong for you, and you may not know it!
The video explains an epically crucial reality about CMMI that many agile (and other) teams are not aware of, leading them unknowingly down a path of self-defeat and damage. All of which could be avoided with this one super-critical piece of knowledge.
You’ll thank me later.
Backstory:
The lure of seemingly limitless opportunities can be quite strong, obviously. And, especially in tough economic times, succumbing to that lure can cause even the best of businesses to act unwisely. Such is the lure of CMMI ratings.
Well, anything that’s very alluring can cause unwise behavior, I suppose. Whether it’s as apparently harmless as indulging in a luscious dessert, spending money on unnecessary luxuries, or any of equally limitless opportunities to make bad choices, doing what we want instead of doing what’s right shows up even when working with CMMI.
This blog is full of examples of such bad CMMI choices, but there’s one bad choice I haven’t mentioned much about. That’s the choice to even try to use CMMI.
When working with a knowledgeable, concerned, trustworthy CMMI consultant, an organization should be steered away from CMMI when their circumstance doesn’t align well with model-based improvement using CMMI. In some cases, it may be a matter of steering towards the right CMMI constellation (e.g., for Development, or, for Services). However, just as whether or not CMMI is right for an organization ought to be discovered before too much energy is put into it, so should the decision about a particular maturity level within the constellation.
No CMMI constellation should be attempted if/when the organization doesn’t control the work that it does. Namely, that the work it does is controlled by another organization, such as a customer. Or, put the other way, CMMI should only be used if/when the processes used by the people doing the work are controlled by the same organization using CMMI to improve them.
At Maturity Level 2 (ML2), almost any type of work can use the practices in that level to improve its performance and to demonstrate that the practices are in place. However, at Maturity Level 3 (ML3), you have to be doing the type of work in the particular constellation in order to be able to use the practices in it. If you’re not doing that type of work, the practices will be irrelevant. Attempting to use the practices when there’s no such work being done will only cause the practices to get in the way and add nothing but frustration.
In particular, if you’re not doing work that involves structured engineering analysis, CMMI for Development at ML3 will be truly unwieldy.
Adding practices for work you’re not doing is an example of the bad behavior many organization exhibit when they’re chasing a level rating rather than hot on the trail of performance improvements. It’s these sorts of behaviors that are somehow rationalized as being beneficial when, in fact, they are unequivocally, diametrically, and everything but beneficial. They are a colossal waste of time and money and detrimental to morale and productivity.
You really need carve out about 11 minutes to watch the video.
Agile is a Service: You May Be Improving the Wrong Things
Posted by agilecmmi on Oct 9, 2011 in Agile, Business, CMMI for Services, Improvement, Kanban, Services, Services vs. Development | Comments Off
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.]
This site.
The opinions expressed here are the authors' and contributors' and do not express a position on the subject from the Software Engineering Institute (SEI) or any company or SEI Partner affiliated with the SEI.
Your Host
Hillel Glazer
Principal & CEO Entinex, Inc.
Email me.-
