Why Do You Want to Be There?
This year, the conference is significantly re-orienting itself towards END USERS. Previous SEPG conferences had a lot of useful information, especially for experienced change agents and consultants in the field.
This year, the focus is on up-and-coming disciplines, established success strategies, and most importantly, direct business performance benefit of using CMMI. In fact, what we’ve seen over the years is that CMMI is working extremely well with other forms of improvement as well as with existing defined service delivery and product development approaches — whether agile, lean, traditional, customer-focused, innovation-focused, or some combination.
CMMI provides a specific framework that is both a way to focus attention on specific needs while also benchmarking progress. Instead of flailing around trying to find where to put improvement energies, or waiting for a long-term traditional approach of process exploration and decomposition, CMMI takes a lot of the guesswork out by leveraging decades of experience and laying out very specific goals to seek to improve performance.
CMMI users have reported their productivity to increase magnitudes of order, costs drop in double digits, and their ability to cut through thick process jungles more quickly than being left alone to their own devices.
Yes, I’m speaking and presenting at SEPG 2013, but that’s the least relevant reason to attend. Come because you want to see what others are doing to marry CMMI with existing (or new to you) concepts; come because you want to hear from other end-users what they’re doing with CMMI to improve performance. And, most of all, come because you want to get and stay ahead of your competitors who aren’t using CMMI nearly as effectively as you will after attending.
SEPG North America: The CMMI Conference is coming soon, but there is still time to register.
This year’s conference program will include content perfect for you if you are:
Beginning to implement–or considering implementation of—CMMI
Seeking resources and best practices for integrating CMMI and Agile practices
Interested in taking your process improvement game up a level
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.
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.
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.
Hillel Glazer Principal & CEO Entinex, Inc. Email me.