Tuesday, September 16, 2014

CMMI vs. Scrum? NO! CMMI + Scrum!

"In this article, Jeff Dalton walks us through a fairly thorough application of CMMI in Scrum settings. He further demonstrates an approach to CMMI that is not only compatible with Scrum, but also uses Scrum and agile thinking to facilitate CMMI! It's not merely a matter of such-and-so Scrum practices demonstrating this-or-that CMMI practice -- that would be both easy and disingenuous. Dalton practices what he preaches and would never lead a company down a path that only solves their performance needs once, leaving them with nothing with which to fend for themselves when circumstances change. Instead, he offers us a delightfully simple and robust architecture that we can use to build processes incrementally and iteratively. How agile!" Hillel Glazer.

Download your copy of this article now, compliments of Cutter Consortium!


http://www.cutter.com/offers/agiledalton.html

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead AppraiserCertified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

How granular does our CMMI process documentation need to be?

Hey, CMMI Appraiser! Settle a bet for us. How granular does our CMMI process documentation need to be? ~ Francis and  Karl

Hey, Francis and Karl! CMMI is a set of best practices. It doesn’t say you NEED to do anything. It asks you to describe how you want people to behave in a way that will make your company great. That can’t be done with documents, forms and so-called “CMMI Certification,” so whichever one of you was betting that the CMMI does NOT require an immense amount of granular detail, you win the bet.


Unfortunately, we see a lot of losers at the wheel of organizational performance improvement. They put all their chips on getting a so-called “CMMI certificate” and hope to win a CMMI Maturity Level 2 or 3. They up the ante with all tons of detailed documentation of definitions of processes.

That’s not how the game is won. You don’t come out ahead by slavishly trying to control your people with mind-numbing, soul-crushing busy-work, such as filling out documents and forms. You’ll miss the whole point of why you’re doing this. Your goal should be to get value from your process – not just to “pass” an appraisal. If you just go for the plaque on the wall, your CMMI adoption will be a disaster.

I think you get my point. You don’t need tons of documents. Why create all that burdensome, expensive process debt? Go to the level of detail that is valuable to you - and no further! As I always tell my clients, engineers are smart people. They don’t need a step-by-step process, they need guidance. And as my clients always point out, engineers will always try to create one anyway!

True. But you don’t need that. All you need is a little guidance.

My advice is that you approach CMMI for what it really is – a toolset to solve strategic problems. You can use CMMI for guidance on caring about the right things to make your organization great. Along the way, you will create a set of documentation that describes how you want people to behave in your company, and it won’t be too granular.

That’s a safe bet.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Monday, September 15, 2014

SPaMCast Question #7: What one big thing can we do to become a great company?

[NOTE: Over the past few weeks, this CMMI Appraiser has been sharing excerpts from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.]

Jeff, give us the key to being a great company. Tell us what this one big thing is and we’ll do it. Is this one big thing CMMI? Is this one big thing agile? ~ Tom Cagley, SPaMCast 

Tom, when people ask me what one BIG thing they need to do to become a great company, my response is always the same: It’s not about big things. It's about LITTLE things.


For example, in my travels, when I meet CEOs, VPs, Directors, and Quality Assurance Managers from a wide variety of companies, large and small, I ask, “What would it be like if everybody on our team knew exactly what was expected of them?”

This is one of those little things that cause people to shake their heads and say, “What do you mean by that?”

And I say, well, think about what would happen if you walked through the company and you literally ask ten developers, “How long are your sprints? How many sprints in a release? When do you do your retrospectives?” If you just ask those simple questions, you'll get ten different answers. This happens everywhere because it is a very typical kind of behavior. And it is an example of the kind of behavior that can be improved with one single practice in the CMMI.

But the goal is not necessarily to adopt CMMI or embrace agile.  The goal is to consolidate the mental model of the members of your team so that everybody is on the same page. It's a little thing, but if we can do that, we can enhance productivity dramatically, without a lot of overhead.

In the context of agile, the CMMI helps you strengthen your way of doing what you do, by helping you build a resilient framework. By embracing lessons of CMMI with agile – or Waterfall, Spiral, or whatever your methodology of choice is – and building a resilient framework, you move closer to being a great company.

Those interested in learning more about using CMMI and agile to be a great company are invited to participate in our upcoming Webinar:

Agile Resiliency Scaling Agile so that it Thrives and Survives” (in conjunction with QUEST 2015)
Wednesday, September 17, 2014 from 12-1PM EDT.
Click here to register for the webinar.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Visit www.broadswordsolutions.com for more information about engineering strategy,performance innovation, software process improvement and running a successful CMMI program.

Saturday, September 13, 2014

SPaMCast Question #6: What does it look like when an organization has improved productivity?

[NOTE: Over the past few weeks, the CMMI Appraiser has been sharing excerpts from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.]

[NOTE II: In today’s post, Tom is following up on a question about the benefits of using agile and CMMI together to achieve higher quality, faster delivery, and predictable, repeatable results.]

Jeff, you say that by focusing on changing behaviors, organizations can be doubling and tripling productivity. How does an organization see that? What is that? Suddenly, more things getting done? More value? Less people? ~ Tom Cagley, SPaMCast

Tom, what organizations will see is a great opportunity to take on more work. That’s what everybody wants, because the more productive they are, the more they more value they can provide for their customers, at cost that everybody is comfortable with.


You know, I’ve never been an advocate of cutting costs necessarily. To me, value is what’s most important. Value is what customers want, and will pay for. There is no shortage of value to be delivered, and no shortage of work to be done. If we are going to meet the demand, we need to learn to change behaviors, so that the people we have can deliver more value. This is not the time to cut costs.

So, you ask, how does a company do this? Well, let’s say you were going to take a large, chaotic, unproductive organization, and transform it into a great company. You have a vision for how this will happen – by delivering more value than your competitors. The way you are going to deliver more value is by getting better at what you are ALREADY doing.

Everyone knows, there is no silver bullet for success in this industry. But if it were me in charge of this turnaround, I’d use agile methods within a CMMI framework to put my company on the path to greatness. Just by applying a few simple concepts, I would be able to take on more work and deliver more value with the same amount of resources as the competitor might have.

I’ll be talking more about this concept of using agile and CMMI on upcoming webinars. I would love to have all perspectives join me by registering below:

Agile Resiliency Scaling Agile so that it Thrives and Survives
Thursday, September 11, 2014 from 1-2PM EDT.
Click here to register for the webinar.

Agile Resiliency Scaling Agile so that it Thrives and Survives” (in conjunction with QUEST 2015)
Wednesday, September 17, 2014 from 12-1PM EDT.
Click here to register for the webinar.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Thursday, September 11, 2014

Announcing NEW “Agile Resiliency” Webinar, hosted by QUEST

Dear Readers,

Last spring, this CMMI Appraiser was honored to be the keynote speaker at the QUEST 2014 conference in Baltimore. Apparently the presentation generated a lot of discussion and debate, as I’ve been invited back to share more of my thoughts on making sure agile stays agile via a FREE webinar: "Agile Resiliency: How CMMI Will Make Agile Thrive and Survive." Be a part of the discussion by clicking HERE.


Not everyone understands at first why this is so important to them. The fact is, throughout their history, large adopters such as Boeing, Lockheed Martin, Rockwell Collins, SAIC and Ford have exerted their influence on every methodology and model they've embraced.

For example, as I mentioned in a recent blog post, there was a day when Waterfall was thought to be innovative, helpful and useful.  (Hard to believe, but true!)  What happened is Waterfall methods evolved and changed to meet the information needs of the large adopters. The same will happen to agile – unless we make a concerted effort to strengthen agile and make it resistant to change.

Whenever I voice this concern, I invariably hear from trusting souls who question why large-scale early adopters would concern themselves with changing such an effective way of getting work done as agile. “These organizations have better things to do than change agile,” they complain. I always respond by pointing out that they don't MEAN to change agile.  They are merely doing business the way they’ve always done business, i.e., in a top-heavy, document-focused, command and control manner. They took a similar approach to adopting the CMMI. They took a similar approach to adopting Waterfall. And they’ll do the same to agile.

The truth is that neither Waterfall, the CMMI, nor any particular process model was ever intended to be top-heavy and document-focused. But that’s the way the large early adopters did business. Thus, that’s how the methodologies and models evolved.

And guess what? Large adopters are STILL doing business their old way! As we speak, there are hundreds of companies being influenced by organizations like General Motors, Ford and Chrysler and hundreds of contractors being influenced by the Department of Defense. What do you think will happen as more and more of them start saying, "Let's be agile!"

I’ll tell you what will happen. It’s what always happens. It happens so reliably, we even have a saying for it here in Detroit, “Suppliers don’t change GM. GM changes suppliers.”

As a supplier, you can have all the best intentions and the right way of going about things, but these large new adopters have tremendous weight and momentum behind what they are doing, and you will eventually get changed. Not because they don’t want to be agile, but because they are NOT agile.

This will not be good for those of us who love agile and want to stay agile.

But there is hope.  This webinar shows you how to fight back by applying the concept of “Agile Resiliency,” a proven strategy for scaling agile by strengthening and reinforcing agile values, methods, and techniques. Agile Resiliency is about integrating the architectural strengths of the CMMI with your agile approach to help you make agile resilient enough to resist the pressure to change – and even scale and thrive.

Check out more information about the "Agile Resiliency" webinar HERE.


See you on the webinar!

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Tuesday, September 9, 2014

SPaMCast Question #5: How do we stop the Agile-CMMI mismatch from happening?

[NOTE: Over the past few weeks, the CMMI Appraiser has been sharing snippets from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.]

[NOTE II: In today’s post, Tom is following up on a question about the perceived type mismatch between agile and process improvement models like CMMI, to which we explained that agile and CMMI are all about the same thing: solving problems.]

Jeff, if agile and CMMI are all about solving problems, how do we stop this mismatch from happening? ~ Tom Cagley, SPaMCast 

Tom, I've become very passionate about this topic over the last five or six years. You're probably familiar with some of the articles and books written about how agile and CMMI can cohesively work together. Several of our agileCMMI publications are available on our web site, which will give people a comprehensive understanding of our view. In a nutshell, there is no conflict between CMMI and agile.  They can -- and do -- peacefully coexist.



Times have changed. Our industry is starting to realize there is no conflict between agile and CMMI. Now, people are starting to say, “You know what? Let's use the CMMI as it was intended to be used, not to get a certification, not as tool to develop processes, which is how in the past so many people use it. No, let’s use CMMI as a tool to make what we're doing already even better.”

And so, the first step is to decide as a company that we want to have these agile values. We want have values of trust and cohesion and all of these things that are driven by the agile manifesto.

Once we have decided this, then we need to implement the solution. And this is exactly where the CMMI becomes so important, because now we've got this really rich and robust tool set. In fact, we’ve got the richest and most robust tool set in the world for this subject. So let’s make the decision to use it to improve and strengthen what we have in place. We can have predictability instead of chaos and all of the wonderful things that CMMI was intended to solve. 

Notice I didn't say, "does solve," because so many companies have taken an inappropriate approach to adopting CMMI. But with a proper adoption of the Model, you can bring robustness to whatever process it is that you decided to implement.

And so I've made a few adjustments with how I talk about getting CMMI and agile to work together. I've changed my language so that I don't often use the word “process” any more when talking to clients. Now I use the word “behavior.”  I'm saying, "Let’s use this CMMI to increase the resilience of the behaviors that we want to see.”

I'll give you an example. Let's say a company would like their team to use Planning Poker (which by the way I think is a great tool).  We’ll use the CMMI to ensure that Planning Poker is giving us the results we want to get, as well as the repeatability of these results. Our focus will be on making sure that everybody's trained and everybody's using it.  That way, we can get maximum value out of CMMI, which means we're changing behaviors and doubling or tripling the productivity of our people.

There's a lot more to share on this topic.  As I said, I've very passionate about it!  For those who would like to know more, we’re presenting the following upcoming webinars on the subject, and would welcome their participation:

Agile Resiliency Scaling Agile so that it Thrives and Survives
Thursday, September 11, 2014 from 1-2PM EDT.

Agile Resiliency Scaling Agile so that it Thrives and Survives” (in conjunction with QUEST 2015)
Wednesday, September 17, 2014 from 12-1PM EDT

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Saturday, September 6, 2014

Can CMMI work for us even if our goal is to stay small and agile?

Dear CMMI Appraiser – as a 9-person start-up software company, we love our ability to be agile and turn on a dime if need be. But we don’t love seeing big government contracts go to large companies that have a CMMI rating. Can a CMMI rating work for us even if our goal is to stay small and agile? ~ Sam C

Dear Sam,

Yes, adopting the CMMI works very well for small companies that are looking to manage their uniqueness is a structured way and achieve a CMMI rating to compete for government contracts. This comes as news to a lot of engineering and software professionals who are new to CMMI and don’t realize that the Model is more akin to a context-driven behavioral model than a process improvement model. Because CMMI is a set of practices that guide you to adopt the behaviors of a great company in the context of YOUR business goals and objectives, the Model helps guide you to be the best small, agile software company you can be.



Let’s use an example you’ll be familiar with. I assume you are using retrospectives to take a look at how you could make the next sprint better on your Scrum project. Without knowing anything about CMMI, you’re probably already executing a number of CMMI practices related to collecting and analyzing lessons learned from projects.

This is true because CMMI guides you to get the most out of your lessons learned, but it does not prescribe how those lessons are to be captured. I’ll say that again. CMMI doesn’t tell you HOW to get better at performing retrospectives. In fact, CMMI doesn’t tell you HOW to do anything! It says, “Here’s what great companies have told us that they do.” Your job is to apply these lessons to what you are doing in a way that makes sense within the context of your business.

This goes for every area of the business. Whether applied to your software development, operations, finances, sales or marketing, CMMI asks you to perform every operation in the business one way – YOUR way.

Another example is peer reviews. If you’re performing routine maintenance on proven code, you might use a simple work-flow based approach. But if you’re writing code for a re-entry algorithm on a space vehicle, a Fagan Inspection might make more sense. Both are peer reviews. CMMI provides a clear definition of what you should do to be a great company, regardless of what tasks you are trying to accomplish, and regardless of the size of your business.

It’s interesting to note, Sam, that CMMI adoption is on the rise in the small business community – especially among those that are agile. That’s because both CMMI and Scrum are designed to help you pursue the same business goals. Both are tools to help solve business problems. They help us improve requirements churn and volatility, for example. They help us meet schedule and budget, and they help us perform the work that we do every day. So there’s no reason you can’t adopt CMMI and stay small and agile.

For more information about how the CMMI works for companies with fewer than 20 people, feel free to visit www.cmmixs.com, and download our white paper, “Shattering the Myths about CMMI and Extra Small Companies.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Tuesday, September 2, 2014

What’s the difference between Verification and Validation, and how do I figure out which project practices support which process area?

[Dear Readers, for the past several months, our good friend Pat O’Toole, CMMI expert and seasoned consultant, has been collaborating with us on a monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month Pat clarifies some of the misconceptions about Verification and Validation.  Take it away, Pat! ~ the CMMI Appraiser]


[PAT: Note – there are a number of verification/validation misconceptions I am going to address in this article.  In other words, I’m not going to constrain myself to answering the question – but why shouldn’t THAT surprise you!] 

The CMMI addresses this question very explicitly, and yet the question keeps coming up.  In the “Introductory Notes” of BOTH Verification and Validation, the model states: “verification ensures that ‘you built it right;’ whereas validation ensures that ‘you built the right thing.”  All you have to do is follow that advice and you can’t go wrong differentiating between the two.


Yeah, right!  To me, this pithy explanation is “cute,” but operationally useless.  For example, if I’m conducting system testing, am I’m trying to ensure that the developers built it right, or am I’m trying to ensure that they built the right thing.  I THINK it’s both – isn’t it?

Over the years I have developed what I believe is a much more useful heuristic – one that’s 90% “good enough” and certainly much easier to apply.  Consider this alternative explanation…

When performing something that smells like V&V, take a look at who is involved in the activity.  If it’s just our engineers and testers, then it’s probably a verification activity.  The best the technical folks can hope to do is to compare the product they’re building or testing to the requirements everyone agreed to, and look for deviations that need to be addressed.  Verification is ensuring the work products meet the requirements.

On the other hand, if the customer, user, or a customer/user surrogate (e.g., Product Management) is involved in a product evaluation activity, this tilts the scale much more heavily toward validation.  When a customer looks at a system we are building on their behalf, they are much less interested in comparing it to the documented requirements, and much more concerned about whether the product is going to solve their problem, be usable by their people, and run on their already-overloaded computers.  These concerns reflect those of validation – fitness for use and the ability to work in the intended operational environment.

So let’s test this to see if it’s easy to apply and helps us to reach the right conclusions.  If we employed only “Stepford” engineers and testers, we would start each project with perfect requirements that were perfectly understood, build the product accordingly and then perform perfect verification that discovered and remediated all deviations from the requirements.  In such a perfect world there would be nothing left to find in validation!

However in our non-Stepford, imperfect world, I contend that any problems found in validation likely results from one of three conditions:
  1. We missed a requirement; (“You didn’t tell us the pinball machine is for a cruise ship!”)
  2. We misunderstood a requirement (“You meant NAUTICAL miles?”) and/or
  3. Our verification activities failed to catch it (“Oooops!”).
Given this new rule of thumb, which product-related evaluation activities are verification, and which are validation?  See if your answers agree with mine…
  1. Unit testing – it’s just us engineers, which would lead us to verification.  However, in the CMMI, all discussions related to unit testing is found in the Technical Solution process area under SP3.1 Implement the Design – so maybe it’s neither.  Ah, but TS SP3.1, subpractice 4, “Perform unit testing of the product component as appropriate,” has a reference to the Verification process area, so our first instinct was right after all!
  2. Integration testing – it’s typically just us engineers and testers, so verification.  However, if the user, customer, or their surrogate participate in some or all of these activities, that also brings a validation component to this activity.  (A single activity CAN be both verification and validation.)
  3. System testing – same as integration testing.
  4. Qualification / customer acceptance testing – because the user, customer, and/or their surrogate are typically involved in such activities, they are primarily validation.
  5. Prototyping – it depends.  If it’s a prototype like sample webpages or mocked up reports or modified process flow diagrams that are intended to be shared with the customer/user to make sure that we’re going down the right path to meet their needs, then it’s validation.  If it’s an engineering prototype – one used to decide which of three alternative technical approaches will best meet the stringent performance requirements (for example), then it’s verification.
One additional note about Customer Acceptance Testing … some people mistakenly believe that if their customer performs unassisted acceptance testing then validation is covered.  What these people appear to forget, however, is that the CMMI is intended to enhance your organization’s capability to develop high quality products, not your customers’!  Your customers’ ability (or lack thereof) to perform thorough acceptance testing says nothing about your organization’s capability (or lack thereof) to perform validation.

Another common misconception about validation is that “Validation = Customer Acceptance Testing.” Validation’s ‘Introductory Notes’ points out, “…validation is performed early (concept/exploration phases) and incrementally throughout the product lifecycle.”  The CMMI legal lawyers will object, saying that the “Introductory Notes” are only “informative” model components – reminding us that only the goals are required!  To address the objection, gently guide them to Requirements Development SG3, “Analyze and Validate the Requirements” – objection overruled!

I firmly believe that most organizations perform more validation than they give themselves credit for.  To lift the veil on these hidden validation activities, ask questions about customer/user/Product Management involvement throughout the life cycle.  What kinds of things do you get them involved in, and what does that involvement entail?  Do you show them mocked-up webpages, sample reports, etc. to elicit their opinions? 

And what kinds of changes do you make based their feedback?  Questions like these will reveal that hidden validation activities that most development groups perform.

Keep in mind that the CMMI suggests that blissful ignorance of performing such activities is better than nothing – in fact, it’s called “capability level 1” – but it’s not as good as actually doing such validation activities “on purpose” – which is the purview of capability levels 2 and 3.  The model also suggests that relying on project managers or engineers to “do what they feel is right” demonstrates more of an individual capability than an organizational capability.  The CMMI would suggest explicitly establishing and institutionalizing the system of practices that provides an organizational validation capability.  You’re probably exhibiting many of the behavioral patterns already, but the model is encouraging you to support it in a way that ensures it is performed consistently, consistently performed, and improved over time.

I have saved what I consider the most important point for the very end – and that is that the amorphous dividing line between verification and validation is something that is only of interest to us CMMI model geeks and that such discussions should probably not be conducted in front of the engineers and testers.  Not only do we embarrass ourselves when such bickering occurs in public, but they really don’t care!  What they DO care about is developing products that delight the customer.  They don’t get hung up on whether a particular activity is “verification” or “validation” – if it’s the right thing to do, they do it.  And THAT’s as it should be!

© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions

“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton.  Please contact the authors at pact.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed.  New questions are also welcomed!

Monday, September 1, 2014

Would achieving a CMMI Maturity Level help or hurt our competitive difference?

Dear CMMI Appraiser – we are an award-winning federal contractor, providing IT services to NASA, the Department of Transportation (DOT) and Department of Interior. We pride ourselves on being very different from our competitors, but lately our developers have been asking us to consider adopting CMMI for its structured framework. My concern is this: if we were to adopt the CMMI, wouldn’t it hurt our competitive difference and make us same as everyone else with a Maturity Level 2 or Maturity Level 3? ~ Sam C.

Dear Sam,

Great question. The purpose of the CMMI is to help any executive, engineer and/or business professional who is trying to create an environment in which your organization can manage its uniqueness in a structured way. You don’t have to “go for a level” – in fact, unless you need to, don't! The competitive advantages of adopting the CMMI are far more important the mere designation of ML2 or ML3. With a proper adoption of the CMMI, you’ll leave the competition in the dust.



It’s counterintuitive, but true. Rather than making you seem the same as everyone else, you can use the CMMI for guidance on emphasizing and leveraging your difference. The Model helps you establish an environment for allowing you to easily operate like the great company you know you can be – for the long term.

So I wouldn’t worry too much about what other people think, Sam. It’s not about changing your business to suit them. The CMMI is about the transformation of the culture of your company. It’s about improving and changing the way your company behaves, so that you build better products, win new business and retain the customers you have.

For more information on using the CMMI as a competitive differentiator, we are hosting a Webinar that shows you everything you NEED to know about CMMI. Sign up today for: “CMMI - Everything You Need to Know” on Thursday, September 25, 2014 at 1PM EST.

Don't miss this great learning opportunity! Register today.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author, and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Sunday, August 31, 2014

SPaMCast Question #4: Does the value of CMMI get lost as a "top-down" directive?

[NOTE: Over the past few weeks, the CMMI Appraiser has been sharing excerpts from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.] 

Jeff, if you go back far enough, once upon a time, CMMI was being driven bottom-up and was struggling to some extent, the same way we're seeing today with agile.  But when CMMI became a "top-down" initiative, did companies lose sight of its value? ~ Tom Cagley, SPaMCast 

Tom, you and I are both very passionate about CMMI and see CMMI as an important tool for improving processes, and not an end-all be-all tool that solves every single problem. Unfortunately, there are still people who see CMMI as a means to a "CMMI certificate" or to achieve a CMMI rating, which they assume WILL solve every problem.  Rather than receiving the value that the framework is intended to provide – higher quality, faster delivery and predictable, repeatable results  – they treat it more like a stamp of approval, 



So you are correct; the value of CMMI has been lost within some organizations that push its adoption form the top-down.  For proof, just walk around Washington D.C. and talk to any of the six or seven thousand companies that are providing IT services to the government. You’ll find that many of them interpret CMMI as a certificate to be had.

This is primarily a Washington D.C. behavior. Around the country we see some different behaviors, but in Washington the typical approach to something like CMMI – and this also applies to ISO and PMBOK and most of the other process models – is for company leaders to say, “We've got this RFP. We’ve got to get it. We can't do business with the government. We need this certificate.”

When the directive comes down from the C-suite to their managers and staff, it often sounds something like this: "You all shall be CMMI Level 3 by the end of the year!" Or whatever artificial deadline they put on their people. They don’t realize it, but essentially they are saying, "You must be a great company by the end of the year" – which is the true purpose of adopting the CMMI.

But what company can do that? It’s just not logical. So engineers are left to try to figure out how to "pass the CMMI certification" and get their so-called “CMMI certificate.” There's only one place that leads to: A death spiral.

Fortunately, we're not there yet. CMMI is still very strong. It's being used throughout the world in a very productive way in many places. And even in Washington D.C. there are many companies that are enlightened and understand what CMMI is and how to use it as a tool for transforming their culture and changing behaviors to put themselves on the path to being a great company.

But I believe there are still many companies trying to force CMMI from the top-down without understanding the real value of the Model. The same will happen to agile, and the value will be lost, unless we commit to making agile resilient.

For those who would like to know more about making agile resilient, we are hosting a Webinar on September 11, 2014: "Agile Resiliency: Scaling Agile so that it Thrives & Survives".

Like this blog? Forward to your nearest engineering or software exec! 

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Thursday, August 28, 2014

What does CMMI say about Agile cross-functional teams?

Help!!,

CMMI Appraiser, I've been trying to work my google-fu on this topic but cant really get a clean cut answer.

IWhen it comes to CMMI certification and utilizing an Agile flavor development methodology, does CMMI care about what domains are doing what work?

Example)

In Agile / Scrum / XP they preach the concept of cross-functional team memebers. Team members that at any given time can play the role of tester and/or developer. If a team is comprised of all developers (reporting to the app dev family) and this team does not contain members of the test domain (so a QA / Test family) does CMMI have concern with this? would this be considered a conflict of interest?

Thanks, Jesse


Dear Jesse,

Thank you for your question.  It’s a good one!

CMMI is nothing more than a model for improving what you are ALREADY doing!  There is no conflict between CMMI and any development framework or set of techniques like Scrum or XP.  

If you using Scrum, and you want to get more consistent value out of your Sprint Planning and Daily Standups, CMMI has practices to help.  If you’re using Pair Programming or Planning Poker, CMMI can help those also.  It’s method agnostic.  A lot of people struggle with this because much of the “press” about CMMI in the past has been focused around the early large-scale adopters (Aerospace, Federal Government, etc), and they were big “waterfall” shops.  But that was only one of many possible approaches.

There is no rule about cross-functional team members being good or bad in CMMI (in fact, there are no “rules” at all).  There is nothing in the CMMI model that requires independent testers/QA.  

Now, we can discuss whether that is a good idea in all situations, but in a typical small scrum team it usually does not present any issues.

Good luck!


Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead AppraiserCertified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Tuesday, August 26, 2014

Waterfall vs. Agile values – and the Process Thunking Layer

Hey, CMMI Appraiser, when our former boss sold the company, we were a highly effective Scrum team. The new company has a traditional Waterfall approach, and management is telling us they want to see Waterfall behaviors like Gantt charts, big sets of requirements and structured activities. They also say, “But we also want to be agile.” How can they have it both ways? ~ Phil C.

Dear Phil,

The problem you are describing happens when leaders and engineers don’t share the same values. To be useful, values must guide behavior, but when values are out of alignment, so are behaviors. Some executives create the process equivalent of a thunking layer, by which they attempt to have it both ways.


What is a process thunking layer?

When Waterfall-oriented senior executives don’t understand what a Scrum team is doing, they have been known to create a layer of behaviors between the two groups. Similar to a custom written thunking layers like we used to write in the 90s so that 16-bit controls could talk with 32-bit controls in software, the process thunking layer is an interface that adds process overhead and more work to project in order for the two sides to communicate. This layer is not  a part of the functionality, but a necessary evil so they can understand the language.

You are probably seeing this in your organization, Phil. You have a corporate layer with Waterfall values, and a Scrum team with agile values. The thunking layer put in place to translate between the two might take the form of someone whose job it is is to provide that translation (darn, THAT'S why we couldn't have that 5th team member?).

For example, agile teams don’t usually have direct project managers, but if the corporate layer is insisting on traditional project data, they will often hire a project manager between the agile and the Waterfall layers. That’s an example of an organizational thunking layer. They would also realize they need a data layer to translate all the extra data the agile team has to produce because management doesn’t understand the values, methods and techniques of the agile team.

The impact of this type of thunking layer is damaging: Not only is the organization incurring unnecessary process debt and wasting time and money, it is also injecting noise into the system. It creates problems with both project data and requirements. Talk about having it both ways...badly!

So it’s not just lost money and time that cause a problem, but defects in the app that result in lots of rework and animosity between the parties.

Good news! There’s a better way.

To bring your Waterfall-oriented management and Scrum teams into alignment, you can use a values-based architecture that links Values, Methods, and Techniques. The organization will then be able to trace a direct link between the company’s values and how work gets done.

Phil, you can (and should) insist that management aligns the values with the methods and techniques of both Waterfall and agile. One way to do this is by applying a concept we call “Agile Resiliency,” a proven strategy for scaling agile by strengthening and reinforcing and tracing agile values, methods, and techniques. Agile Resiliency is about integrating the architectural strengths of the CMMI with your agile approach to help you make agile resilient enough to resist the pressure to change – and even scale and thrive. The Agile Resiliency Framework removes the thunking layer.

By definition, the Agile Resiliency Framework arms you with the tools you need to help leadership be successful. It provides a landscape for creating positive change by defining the roles of management and Scrum teams and guides the behaviors that everyone needs to exhibit. When you know what the right behaviors are, and what that looks like, you can use the Agile Resiliency Framework to strengthen your agile approach and help your senior execs understand what’s happening and why it is valuable from a business standpoint.

Get more information about helping your executive team develop an Agile Resiliency Framework on our September 11, 2014 Webinar: Agile Resiliency: Scaling Agile so that it Thrives & Survives.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Monday, August 25, 2014

SPaMCast Question #3: Is there a type mismatch organizationally between agile and process improvement methods like CMMI?

[NOTE: Over the past several days, the CMMI Appraiser has been sharing excerpts from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.] 

Jeff, One of the terms that you used for the imbalance between the way managers versus developers see agile was a “bottom-up, top-down mismatch.” How do we start to take that apart and make sure that there's not a mismatch but some sort of meeting of the minds? ~ Tom Cagley, SPaMCast 

That's a fantastic question, Tom. Yes, there is a type mismatch organizationally between agile, where agility is an aspirational concept, and process improvement methods like CMMI, which are operational in nature. On the one hand, you have engineers at the lowest level of the organization trying to push values uphill. And on the other you have the C-suite pushing down the process improvement Model without getting the team to own it.

So we have this type mismatch of aspirational versus operational, and I'll tell you, Tom, it ain’t pretty!



Let me give you an example. The agile manifesto guides us to adopt certain values. Those values, as we all know, are to collaborate with our customers, to have openness, to have courage, to have trust in our organization, to be iterative and incremental. These are values that companies need to adopt. But here’s the problem: We're seeing these values being adopted at the team level, whereas they really need to be adopted in the C-suite. The CEOs, CIOs, CTOs of companies should adopt the values and drive them down throughout the organization so that the culture of the company adopts those values. But that's not what we're seeing. We're seeing it being adopted at the lowest levels of the company – and they are trying to push those values uphill. That’s not sustainable.

Conversely, process improvement methods like CMMI, which are operational in nature not aspirational, are being driven from the C-suite, and not being driven at the lowest part of the organization where the operational activities take place.

This is our great challenge. As an industry, organizationally, we are inverted. This adds tons of overhead and unneeded activity. To fix it we have to start working with our executive teams to start, not on agile, not on CMMI, but on values. We have to start working with them to help them really understand that it's values that drive everything in the company, and values are way more than a poster on the wall.

Our values go right to the core of why we do what we do, and what kind of company we want to be.  That's why it's so important for the C-suite to get this right.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Friday, August 22, 2014

SPaMCast Question #2: If the large adopters continue to change agile, will agile become just a shell of a word?

[NOTE: Over the coming weeks, the CMMI Appraiser will be sharing snippets from a recent conversation with Tom Cagley on SPaMCast about whether agile is resilient – i.e., whether it will be able to spring back into shape after being bound or compressed by the pressures of development and support – and how frameworks like the CMMI can be used to make agile more resilient. Listen to the full interview at SPaMCast 296.] 

Jeff, If the large adopters continue to change agile, will agile become just a shell of a word? ~ Tom Cagley, SPaMCast

Tom, that's exactly right. And it won’t be the first time something like this has happened. There once was a day when Waterfall was considered the new, cool thing, and everybody loved it. Life was so simple then!



I am old enough to remember when people were saying, "Let's do this really cool idea, where we can make projects predictable. We can make people more productive. We can get everybody to understand and we can collaborate.” All of these words were being used back in the 1970s and 80s. Unfortunately, large adopters of the method have turned Waterfall into a shell of an idea. If this continues, there's no reason that agile won't go the same way.

I'm a big fan of history. I believe very strongly that history continues to repeat itself over and over and over again, and always has and always will. And for the science fiction fans among us, you saw this on Battlestar Galactica, where they always said over and over again, "What's happened before will happen again." 

This problem of taking a great concept and turning into a shell has all happened before. It will all happen again. And the same thing will happen with agile unless we take steps now to strengthen and make it more resilient.

What is resilience, anyway? The formal definition says resilience is power or ability to return to the original form or position after being bent, compressed, or stretched; elasticity. It is also described as the ability to recover readily from illness, depression, adversity or the like; buoyancy.

I believe these are two very apt definitions of resilience, given what is happening in our market and the influence of some of the newer players – such as the federal government, and big defense contractors – who are demanding that their vendors “go agile.”

In my opinion, this why we need a resilient model.

Check the Broadsword web site (www.broadswordsolutions.com) for our next webinar on Agile Resiliency.

Like this blog? Forward to your nearest engineering or software exec!

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students.

Wednesday, August 20, 2014

Register for "CMMI - Everything You NEED to Know!"

Dear Readers,

Coming soon to screens near you!   If you have been tasked with, or interested in, transforming your organization into a high-performing, lean, and productive team, Broadsword is hosting another FREE Webinar for engineering and software professionals like you, on Friday, August 21, 2014 at 1PM EST.  We hope you can join us.



Watching this Webinar and learning everything about CMMI is an excellent choice for anyone who needs to get a grasp on improving, changing and elevating performance. At the deepest level, the CMMI provides you with an understanding of the way your company behaves, so that you can build better products, win new business and retain the customers you have.

That’s the promise of CMMI. The Model is all about the transformation of the culture of your company. It’s about improving and changing the way your company behaves, so that you create an environment in which the organization can manage its uniqueness in a structured way

So, whether you have been told you need to achieve a so-called “CMMI Certification” or you have been working with CMMI for years, you’ll want to check out the Webinar. You are sure to pick up some new ideas to help you get better at what you are ALREADY doing.


Like this blog? Forward to your nearest engineering or software exec! 

Jeff Dalton is a Certified SCAMPI Lead Appraiser, Certified CMMI Instructor, author and consultant with years of real-world experience with the CMMI in all types of organizations. Jeff has taught thousands of students in CMMI trainings and has received an aggregate satisfaction score of 4.97 out of 5 from his students. 

Monday, August 18, 2014

Why you MUST involve the right stakeholders

[Dear Readers, for the past several months, our good friend Pat O’Toole, CMMI expert and seasoned consultant, has been collaborating with us on a monthly series of CMMI-related posts, "Just the FAQs." Our goal with these posts is to provide answers to the most frequently asked questions about the CMMI, SCAMPI, engineering strategy and software process improvement. This month Jeff reveals why it critical to identify and involve the right stakeholders. Take it away, Jeff! ~ the CMMI Appraiser]


We’re an agile team and everything we do is “face-to-face.”  You might say we “specialize in collaboration.”  Why should we care about “GP2.7: Identify and Involve Relevant Stakeholders?”  It’s seems like defining a process for this doesn’t deliver any value.

I agree, you shouldn’t care about GP2.7. You should REALLY care about it!

The entire premise of “agile” is predicated on strong collaboration, transparency, and, most of all, being engaged.  So the real question is, why would you even THINK this wasn’t important?
Perhaps the words are getting in the way. The CMMI, rivaled only by a Piers Anthony novel for its esoteric lingo, may not say it in an “agile way,” but the authors meant pretty-much the same thing you do.  Another way to say it might be:

“We need engagement, and where the heck are they?”

Years ago, when I was a CIO of a software company, members of our development team came into my office complaining about team members not participating in important project events:

“He never comes to the meetings we put on his calendar!”

“She plays with her email during every design review!”

“The business customer never shows up!”

“The other developers don’t even LOOK at the code before a code review!”

That sounds horrible!  And we were using Scrum too.  THIS WASN’T SUPPOSED TO HAPPEN! 

Their complaints required some additional investigation.  So I asked them, “how big a problem is this?”  and “which meetings were worse than others?”

Crickets.

Don’t get me wrong, they thought it was a BIG problem, and it REALLY annoyed them, they just couldn’t tell me how big it was.  Or how small, or how much risk it introduced into the project.  Nothing.

Or as I like to call it, whining.  Wah wah wah!

By now my radar was starting to overheat.  “Wait, agile is all about engagement, but you’re saying people are not engaged?” Ouch.  My brain was hurting!

Agile teams are usually pretty good at engaging in “ceremonies” that are defined by Scrum (daily standups, sprint demos, sprint planning, etc), but are similar to traditional projects when it comes to engaging with the other  – no less important – events like design reviews, code reviews, testing, and other valuable, but not specifically “agile,” events.

Those of you who follow my blog know that I’ve been writing a lot about Agile Values, and that without them adopting “agile” is bound to end up being a frustrating experience.  This is because agile is really a set of values, not a method or set of techniques.  Agile techniques, like planning poker for instance, were designed in direct support of the values, not the other way around.  In other words, there should be direct traceability between agile values, agile methods and agile techniques. Holding daily-standups doesn’t make you “agile” unless your organization values failing-fast, transparency, and collaboration.  If they punish you for uncovering risks and issues every day, those daily standups will go the way of the buffalo right quick!

So, there I was, listening to my agile team members complaining about their own team … not being agile. Ugh. 

At the time I didn’t know much about GP2.7, in fact I had never even heard of it.  But I did know that in order to understand the risks of lack of engagement I needed information, so I decided to do something about it.   GP2.7 is, after all, all about risk.

A customer I had been working with had been playing around with an idea called “TeamScore” to keep track of stakeholder attendance for status meetings.  I thought that since “agile” is ALL about engagement, why not apply TeamScore to all events (as identified by the project’s defined process) and use it as a primary indicator of agile project health?  If engagement is a pre-requisite for agile projects, it seemed like understanding this data was a pre-requisite for running a successful agile organization.  It turned out to be a good guess that paid dividends well beyond the investment.

We first implemented Release One – an estimate vs. actual record of attendance at all ceremonies and events.  This revealed three facts:
  1.  At most of the events the attendance was not what was planned.
  2.  That wasn’t all bad, because we discovered that teams often clogged up people’s calendars with meetings they didn’t need to attend (which explains why some of them were not showing up).
  3. Some of the people attending didn’t need to be there, but they showed up anyway and ignored everyone (hey, it beats working!).

As soon as we started posting the scores in public team members came out of the woodwork! Those who were supposed to be there started showing up, and those whose attendance was superfluous self-selected out, removing waste from the value chain and increasing the bandwidth of the organization.

SCORE!  Instant improvement!

Having successfully spiked TeamScore in Release One, Release Two of our little experiment introduced a multiplier for engagement at each event.  If someone was unprepared, played with their phone the entire meeting, or constantly vanished to make a call (you know who you are!), we applied it to their portion of the average.  We didn’t report on individual scores, only the TeamScore. This introduced other ways for us to collaboratively set expectations, save money, and reduce our opportunity cost.  All because of GP2.7!

So learn to love it.  It can make the difference between saying your agile, and being agile.

© Copyright 2014: Process Assessment, Consulting & Training and Broadsword Solutions

“Just the FAQs” is written/edited by Pat O’Toole and Jeff Dalton.  Please contact the authors at pact.otoole@att.net and jeff@broadswordsolutions.com to suggest enhancements to their answers, or to provide an alternative response to the question posed.  New questions are also welcomed!