CMMI and Agile Blog

December 27, 2016

What I’ve learned about software development and why it seems opposite to everything I was taught

In this blog I would like to share with you what motivated me to write my latest book, which is titled: “It’s All Upside Down”.  And I would like to tell you a little bit about what’s in Part I of the book.

So let’s start with the motivation. The title of this blog post is actually the subtitle of the book, which has a lot to do with my motivation for writing it.

In just the past few years I have made such drastic changes in how I help software development teams as a coach that it often appears what I am recommending to my clients is the complete opposite of many well established long held software engineering principles.

Now, in fact, my recommendations are not really in opposition to these principles at all—but they appear to be because what actually works in practice oftentimes isn’t what we think based on what many of us have been taught.

This was my major motivator for writing this book. I wanted to share true stories of what we have recently discovered really works for successful software development teams in practice.  There are eight stories in Part I of the book that all occurred in 2015 and 2016.

As I share the stories I also highlight 26—what I refer to as– “upside down” principles.  Now, the principles themselves are not really upside down.  What is really upside down is what many believe they need to do to effectively apply these principles.

To help communicate this message I focus each story around three key items:

  • First, the activities successful teams conduct in practice
  • Second, how much of these activities they conduct
  • And third, when they conduct each activity

 

I expect many readers will be surprised to learn how little time successful software development teams spend on certain activities that have traditionally received high focus, and–even  more importantly–  how much time is actually spent by successful teams on activities that traditionally have received little attention.

In closing this blog I would like to point out that I am certainly not the first person to have observed that what works best in practice often doesn’t match the theory.

It is also worth pointing out that this observation is not unique to software development. As the immortal New York Yankee baseball legend Yogi Berra once said:

“In theory there is no difference between theory and practice.  In practice there is.”

Now, in this blog I have referred to both principles and best practices.  In my next blog I will share with you why I focus more on principles in the book, and I will explain the power that principles can bring to a software development team’s performance.

Click to purchase the book

Advertisements

September 16, 2014

How do you keep your audience engaged when they don’t understand your language?

In August, 2014 (this year) I faced this challenge when speaking at the Latin American Software Engineering Symposium (LASES) in Barranquilla, Columbia. The night before the talk Dr. Carlos Zapata and I came up with an idea that not only worked, but also generated more questions than I ever imagined.

The title of my talk was: Essence: A Practitioner and Team Performance Perspective.

Take a look at this video to see how we pulled this off.  Below the link to the video find a sampling of the questions I received and how you can locate them quickly in the video.

Following is a sampling of the questions I received during the talk:

  1. Why are there only 7 alphas in the Essence kernel?
  2. How long will the SEMAT community work on Essence?
  3. Why don’t we see practices represented on the kernel?
  4. What is the vision for how companies will represent their practices using Essence?
  5. Will there be more disciplines added to Essence?
  6. How is the kernel changed, and what changes are coming?
  7. What criteria was used in selecting Essence checklists?
  8. What is your vision for the future of Essence?
  9. How would you sell Essence to companies?
  10. Where are we headed with practices on top of the Essence kernel?
  11. What is the definition of practice from the point of view of the Essence kernel?
  12. How will practices be captured in the Essence framework?

If you don’t have time to watch the entire video, jump to the end of the video where you will find, along with the 12 questions above, 30 more key questions/concrete examples listed and a reference to where you can find them quickly in the video (minutes and seconds into the video).

February 3, 2010

Why Use the CMMI in an Agile Organization? And When You Shouldn’t

                                                     by Paul E. McMahon, PEM Systems

If you use an agile approach on most of your software projects and you are successful why would you consider using the CMMI Process Improvement framework? The natural thought many have is:

“Why should I care about the CMMI?” and

“Wouldn’t the CMMI just hurt our agility? and

“What value could the CMMI possibly add in our organization?”

First, I don’t believe the CMMI is right for every organization—especially if it is used the way I commonly see it used today focusing on just the attainment of a formal appraisal level.

Second, all the questions listed above should be asked and answered to your satisfaction before you decide to embark on a CMMI initiative regardless of how you intend to use it. It is true that the CMMI model could end up hurting your organization more than helping it. What I hope you can take away from this discussion is some assistance determining the answers to these questions with respect to your organization.

Answers To Key Questions For Your Organization
So let’s get back to those questions. The best way I know to help you get to the right answers is to share a couple of case studies of others who faced the same questions. The first case study is an organization I refer to as BOND. (For more details on the BOND Case Study refer to Chapters 4 and 5 in my book, “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement” –Available from Addison-Wesley, June, 2010).

BOND was a successful agile organization, and the owners came to me and said they wanted to start a CMMI effort. The reason they gave is they were afraid at the pace they were growing they couldn’t sustain the way they were currently operating. A specific example is that the two owners did most of the new business work, and early on did most of the project management and interaction with the customers. But now they were growing rapidly due to their success and they knew they needed to delegate more of these responsibilities deeper into the organization. But they also made it very clear that they didn’t want to lose the successful Agile culture that had brought them their current success and growth.

This brings us to the first key point that they stressed with me:

Make sure you don’t break what is already working well and got us where we are today.

To achieve this we instituted a key rule in applying the model.

Key Rule: Only change behavior if there is a clear problem in the organization that we are solving.

To implement this rule I told the CMMI Process Improvement team that we will add nothing to the current agile processes using the argument that we had to do it because the CMMI dictates it. We did add what we called “stretch points” but only when we could explain in the training WHY this helped the organization. This strategy is part of the answer to the question:

“Wouldn’t the CMMI just hurt our agility?”

The answer is, yes it can, if you use it the wrong way—that is by dictating practices because you think the CMMI requires it. When you take this approach—which many organizations seem to do today–you are indeed putting your agile success at risk.

The strategy we employed would not allow that to occur, and contrary to what many belief this strategy is actually the best strategy to actually succeed with a formal appraisal and rating.

So now what I want to focus on is the “stretches” we all agreed to, and the rationale that was used during training to explain how these stretches helped the organization. BOND was a successful Agile organization, but we did find areas that all agreed where the organization needed to stretch to help the organization sustain its agility and success as it continued to grow. So what we are now going to talk about will help you answer those other two questions:

Why Should I Care About The CMMI? And

“What Value Could the CMMI possibly Add to Our Organization?”

Keep in mind that I don’t believe the CMMI is for every organization. For example, you may not need the same stretches BOND needed because every organization has a different situation. The right answer for you is likely to be different from the right answer for BOND.

What the CMMI model does for us is to help us ask the right questions. It shouldn’t be used as a set of dictated practices which is a common mistake applying the model in many organizations.

Knowing When to “Stretch” In A Successful Agile Organization
When I started helping BOND one of the first things I did was spend time talking to the workers and conducting an informal gap analysis against the CMMI model. Because the organization was growing rapidly the two owners had already started delegating Project Management responsibilities deeper into the organization. In my interviews a common concern I heard was that many of the next tier leaders were being expected to pick up these added management responsibilities, but they weren’t being relieved of their previous responsibilities and they were unsure exactly what was now expected of them as the organization was growing.

A “stretch point” all agreed could help this organization was to define roles and responsibilities in the organization. Out of this activity came a new role we called the Project Engineer. This role was essentially that of a project manager. We also instituted training of Project Engineers so they would know their expectations and have the skills needed to carry them out.

As the organization grew it also became clear that how communication occurred between these new Project Engineers and Senior Management needed to be more clearly defined. When the organization was small most communication occurred verbally, but now with the growth verbal communication was starting to break down as people were becoming busy and forgetting to follow up on actions that may have resulted from a brief hall way conversation. This led to another “stretch point” to define clearly Senior Management Briefs and what information should be in these briefs and to start conducting them on a regular basis.

Most of the Projects at BOND—when the organization was small– ran on their own with little sharing of information across projects. They used many common agile practices, but they had no formal training in these practices within the organization. When new people came into the organization they learned by watching and talking to others. Lessons from one project were learned by others only when they were informally shared such as through lunch time discussions.

Because BOND was successful we didn’t want to change many of these informal approaches that were working. But because they were growing it was becoming clear to many in the organization that these same informal mechanisms that worked well when there was less than twenty people in the organization didn’t work so well when they were getting close to one hundred people.

As a result we kept many of the informal strategies that were working but we wrote them down and trained and institutionalized them in support of the agile culture. Our approach was not to change behaviors that were working, but to support current behaviors where communication was starting to breakdown due to growth. This is the answer to the questions:

“Why Should I Care About the CMMI?” and

“What Value Could The CMMI Bring To Our Organization?”

Stated a little differently, the value the CMMI brings is to help us ask the right questions at the right time and put the right improvements in place so we know what to do when things don’t go exactly according to the plan. Now lets, talk a little more about the value of written processes.

The Value of Written Processes: What To Do When Things Don’t Go Right
Let me now share a little about another case study that I refer to as NANO to help you see another aspect of the potential value of the CMMI in an Agile organization (For more details on the NANO Case Study refer to Chapter 6 in “Integrating CMMI and Agile Development).

BOND was a successful agile organization that was applying Agile practices as intended. But not all organizations who refer to themselves as “agile” implement agile practices correctly.

There are also what I call “agile like” or “wannabe agile” organizations. These are organizations, that are trying to be agile, but are missing key ingredients of true agility. The CMMI can help these “wannabe agile” organizations find their right level of agility. NANO is a successful “agile-like” organization that is growing, but knows it can’t sustain the way it is operating.

Let me give one story from NANO which demonstrates how the CMMI can help an “agile-like” organization. One of the Senior technical leaders at NANO told me he believed in process, but didn’t think the work he did was relevant to process. I asked him to explain. He said he often has to work out a design for a new approach on short notice and the way he does it is a very dynamic and creative process. He explained that often the director would call him up with a problem that needed a fast solution. After taking a couple of days to analyze the problem he would call the director back and they would brainstorm the ideas over the phone. Then the director, if he liked it, might ask him to write up his ideas in a white paper. The director would email it to others to get their comments. If they liked it he would next take it to a lab and prototype it before making any final decisions. He then said he thought what he had described should make it clear to me why he couldn’t follow a process.

What became clear to me after listening to this was his belief that any kind of activity that involved thinking, brainstorming and learning was outside the bounds of process. He seemed to believe that until you could give some one exact “cookie cutter” steps that required no further decisions any work should not fall under process. At the conclusion I told him while he didn’t think he followed a process, he actually did follow a sound process. He had described it to me including the stakeholders (reviewers), and products (white paper, results of prototype). I also shared that just because he didn’t know where it would lead was no reason not to follow a documented process.

By writing it down others could learn and follow it too. We also could ensure we remembered all the people who should review it ahead of time, and we could write down the criteria he uses to make decisions so others might know and follow it as well. I often see stakeholder involvement weakness in agile organizations, especially those organizations that are growing rapidly.
This relates to a common mis-belief that processes are only for well defined “cookie cutter” activities. In reality a good CMMI level 3 process helps you the most when things don’t go according to the plan because it helps you remember the things we often forget under stress which is common on aggressively scheduled high risk efforts.

So far we have been focusing on how the CMMI can help an agile organization. So when shouldn’t an organization use the CMMI?

When Shouldn’t I Use the CMMI?
If your organization is not growing, if your workforce is stable and you aren’t bringing in new people, if everyone knows their role, and everyone knows who to involve and when to involve them– then the CMMI may not be right for your organization. But also think about the risk to your future survival if you are answering all these questions in the affirmative.  Change is essential to survival.  By asking the right questions and thinking about the factors specific to your organization you can make the best decision to help your organization sustain its success. 

For more information on CMMI and Agile refer to www.pemsystems.com.

Create a free website or blog at WordPress.com.