CMMI and Agile Blog

January 30, 2017

Avoiding two common software project troubled paths by “being agile” rather than “doing agile”

This week I want to talk to you about two common troubled project paths, and give you some simple tips to avoid both.

The first troubled path is putting too much effort into documentation. When you catch your project heading down this path stop and ask:

What is the driving need behind our documentation requirement?

Often there are two driving needs. First, your customer or senior management may be looking for some kind of assurance that the software team is doing the right things.  The second reason is to help users and maintainers once the software is deployed.

Unfortunately, traditional documentation isn’t very good at meeting either of these needs. It isn’t good at helping users and software maintainers because often it isn’t trusted to be kept up to date after delivery.  And, historically, documentation hasn’t been very useful to software teams at helping them create high quality software.

The second common trouble path is reacting to the first troubled path by declaring “we’re agile!” –and throwing out the essentials for high quality software along with the documentation.

Now, today, it is a fact that we are seeing more and more organizations trying to increase agility, but many of these same organizations are struggling to figure out how to “become agile” without jeopardizing essentials for success.  And in a moment I am going to explain more what I mean by that phrase “become agile” because I may not mean what you think.

But first, a little background. You may know that in previous blogs and publications I have talked about Essence.  Essence is a framework that captures essentials for high quality software in a simple way—and most important to today’s topic—those essentials are independent of the degree of agility you are driving for with your teams. Essence also includes a simple language to express practices on top of the essentials to give guidance to your teams.

Today I want to talk to you about three simple parts of an Essence practice and how these parts can help your teams find their right level of agility while not jeopardizing essentials for success and help you avoid both common troubled paths.

Those three parts are:

  • the purpose–or goal– of the practice;
  • the activities conducted as part of the practice;
  • the work products produced.

Activities in an Essence practice are what people actually do when carrying out a practice.  They can vary greatly in prescriptiveness. In other words, you can provide activities in your practice that just specify “what” people must do or you can be much more prescriptive specifying in detail the “how to” side of your practice activities.  Similarly, the degree of detail specified in a work product can vary greatly.

Now, let’s look at some examples from my “Upside Down” book.

In Story Two in Part I of my book you learn about a team that came up with an innovative approach to achieve the goal of their sprint review practice when they learned a key stakeholder could not attend the meeting. They actual got on an airplane and went to the client’s site to engage that customer and get their feedback.

The point I want to emphasize here is that the real goal of the sprint review practice wasn’t holding a meeting called a sprint review which is what too many teams get overly focused on when they blindly zero-in on following specified “how to” activities in highly prescriptive practices.

Stated differently, what we are seeing too often is teams falling into just “going through the motions” of prescribed activities. Other authors have referred to this as the difference between “being agile” and “doing agile”.   And, to be honest, I really didn’t understand this difference until I observed it in one of my own client organizations.

What you learn from that story I just referred to is how a team stays focused on the real goal and figures out a creative way to achieve that goal which is gaining the buy-in of key stakeholders—not holding a meeting called a sprint review.

In that same story you learn about a challenge the team faces with a tester having difficulty communicating with developers.  In this case, the team came up with an improved testing practice that included the activity of developers placing a note in the ticket to the tester.  The note in a ticket could be viewed as an example of a very lite work product—not a heavy documentthat helped the communication problem.

In this story it is important to understand that the goal of the testing practice wasn’t to create a note in a ticket.   The real goal was improving communication between developers and a tester. Placing a note in a ticket was just one possible activity that could help the team achieve the real goal of the practice.  And in this story you learn how the team understood that in certain situations if it made more sense to just get up from their workstation and go over and talk directly to the tester that was an option they could and should use.  This is a perfect example of “being agile” rather than “doing agile”.

What you learn from these stories is that where teams often get in trouble is when they start confusing the activity they conduct as part of a practice, or the work product they produce with the goal.  One simple way to help yourself is to keep asking yourself are we are getting too much into “doing agile” –  or just going through the motions of our rituals, such as sprint reviews even when the key people can’t attend?

Or are we “being agile” by keeping focused on the real goal and coming up with innovative solutions when necessary, such as finding creative ways to engage our stakeholders when they can’t make it to our sprint reviews, and getting up from our workstations and walking over to talk to a tester when their might be some risk of misunderstanding.

One caution here, if you decide to allow more choices in your team’s practice activities by making them less prescriptive– it is also highly encouraged that you provide clear limits to the activities, and coaching in these limits, so the team does not fall into chaos.

Always keep in mind that activities and work products are important parts of a practice, but they should never be confused with the goal of a practice.

When we see this confusion starting to happen it is often a sign that an organization is falling too much into the “doing agile.”

Use these simple practice tips when you are developing your practices and coaching your teams, and you might just find it easier than you think to avoid both common troubled project paths and find your right level of “being agile.”

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

September 23, 2015

What’s the Difference Between a Practice and a Pattern and How do they each Improve Performance?

What’s in this Blog

In this blog I answer this question, as well as share status of work I am currently doing using the new Essence framework and patterns with two of my clients.

Blog

I recently started reading a great book titled The Pragmatic Programmer by Dave Thomas and Andrew Hunt and was pleasantly surprised to see a discussion on patterns. At a number of conferences I attended this year the subject of patterns and how they relate to practices was a common discussion topic.

So just what is the difference between a practice and a pattern and how do they each improve performance?

To help you understand let me step back and explain some activities I have been involved in over the past few months and how I am using Essence and patterns to help two of my clients improve their performance.

In June this year I talked at the Agile West Conference on the subject of patterns –http://conferences.techwell.com/archives/bscwest-2015/sme-profiles/paul-e-mcmahon.html, and I gave a workshop at Binghamton University –http://www.binghamton.edu/watson/industry/professional-development/programs/essence.html, on the topic of Essence, the new OMG standard (www.semat.org). I explained in my talk how Essence differs from other popular frameworks and how organizations can use it to help discover their own best patterns.   In August I gave a similar keynote address and workshop at Agile Africa.

As I explained in an interview at Agile Africa in August I have started referring to the patterns I am sharing as “thinking patterns” because they help practitioners make better decisions.

Thinking patterns differ from practices in that they set a specific context related to an organization’s current pain points. This is key to getting a discussion going in the organization related to where performance improvement is needed. Essence checklists can be used to help stimulate the discussion– not to tell the team what to do– but to get the team to decide what they should do to improve their performance given their specific situation.

What is great about Essence is that it is independent of any specific method so any team can use it. It doesn’t matter what practices an organization is currently using. It can help teams discover their own best patterns– and anti-patterns they need to avoid– leading to improved practices and better performance.

I have been involved in the software development business for forty-two years and I am only now finally discovering that we have spent a great deal of time defining processes (or practices) and the effort we have put into this activity has in too many cases failed to payback in real team performance improvement because they are not giving practitioners the real help they need to solve many of the challenges they face each day.

We still need processes, but processes help primarily when you are a beginner. Once you have moved past the beginner stage, practitioners often need more focused guidance related to the specific challenges they face each day.   This is where Essence and patterns can help.

As an example, I am finding that Essence is a really good framework to help organizations that want to become more agile to improve performance but are fearful that they might lose critical disciplined engineering processes as a result. This is a valid concern because a lot of companies when they jump to agile, miss essential fundamental engineering practices that they still need to conduct.

Essence provides the fundamental common ground that helps teams continually ask the right questions to ensure they are not losing essential engineering practices as they move their organization to a more effective way of working.

You may have heard the phrase; “With Essence your practices come alive,” and, “Essence practices are what practitioners really do, not what someone thinks they should do. “ I have been using Essence with one of my clients for the past few months to help them address specific pain points, and I am just now getting started using Essence with another client to help them rapidly improve their performance.

What I am learning is that patterns are a great vehicle to make your practices come alive in the eyes of practitioners because they provide concrete examples in how to think through real challenges leading to better decisions given your specific situation.

Over the coming months I am planning to share results from my two current projects and hopefully share successful case studies using Essence and thinking patterns together to improve performance.

September 24, 2014

Why Software Engineeering isn’t Like Other Engineering Disciplines and How it Changes the Game

A new article has just been published that might be of interest to those following the work of SEMAT.

http://ezinearticles.com/?Why-Software-Engineering-Isnt-Like-Other-Engineering-Disciplines-and-How-it-Changes-the-Game&id=8735903

As always, comments are encouraged.

July 17, 2014

Turning a Weakness into a Major Strength In My New Book “15 Fundamentals…”

I just released a new book titled, “15 Fundamentals for Higher Performance in Software Development.”  You can learn more about the book at www.amazon.com (paperback book or kindle store) or at www.leanpub.com/15fundamentals.

In this, my first of a planned series of blogs about the book, I want to share some background information about how the book evolved and how I was able to turn a weakness into a major strength of the book.

If you have been following my blogs over the past few years you probably know I have been involved since 2010 in the SEMAT (www.semat.org)  initiative.  SEMAT, just last month, achieve a major milestone with the Object Management Group formally adopting the Essence Specification as an OMG standard.

When I started to write my just released new book close to 4 years ago I did not plan for it to include any discussion on SEMAT or Essence.  My intent was to describe a problem that the software development community faces that I felt needed to be discussed more openly.  You can learn more about the problem at:

But as I moved forward in writing the book in parallel with my work on SEMAT I started seeing more and more areas where SEMAT’s Essence framework could help to solve the problem I was talking about in the book.

At first I was unsure how to address this because I did not want to disrupt my  planned flow of the book, so I decided to interject sidebars in the book explaining how Essence could help to solve the problem I was describing.

I had twenty-one reviewers of this book who reviewed multiple versions over the last three years. Only eight of those reviewers had any knowledge of SEMAT/Essence before reviewing the book.  Unfortunately, many of my reviewers gave me negative feedback on the new sidebars with comments such as:

“I find the sidebars distracting,”

“I don’t get this Essence thing,” and

 “The alpha idea makes my head spin”. 

Multiple reviewers suggested that I break the book into two books – taking all the Essence material out of the first book, having a second book just about Essence. Clearly these sidebars had  become a weakness of the book that I would need to overcome.

One reviewer who was a real practitioner and knew nothing about SEMAT or Essence suggested that I take all the  SEMAT/Essence specific material out of the first two parts of the book (first 12 chapters/ about 150 pages), and replace the sidebars with a more general “framework vision” that explained in simpler terms what was needed to solve the problem I was talking about.

He suggested that I use no “process-freaky” words in the sidebars.  This was a project manager in a large US Defense Company who is a very practical oriented manager.  He then said I should keep the Essence framework discussion in the book, but present it late in the book showing how it meets the requirements of the framework vision and how it can help to solve the problem I had discussed in the first two parts of the book.

This is the path I took, and most of my reviewers not only agreed with this approach, but some even went so far as to say they thought the new framework vision was now one of the major strengths of the book.  It was particularly good to hear that the reviewers were able to easily grasp the vision and agree with it, as it now was being presented in the new way.  I now think of this framework vision presented in Parts I and II of the book as the requirements and Essence, as presented in Part III of the book, as an example of one way to implement those requirements.

One reason I wanted to share this story with you is because in Part III of the book where I do talk about Essence I do so from the perspective of how it can help to solve a major problem the software community faces today.

As it turned out, taking this approach achieved another goal as well. Whenever I have spoken at  Universities or Conferences in the past about Essence, there always seemed to be at least a few people who would ask:

“Why do we need Essence?” 

Or

“What problem is Essence going to solve that the other aids we have today like Scrum, CMMI and Lean Six Sigma don’t already handle?” 

By presenting the framework from the perspective of how it can solve a real problem the software community faces, answering those common questions becomes much easier.

This leads us to an important question.

Why is it so difficult for many people to grasp the value of the Essence framework when first presented to them?

Some have observed that it could be because Essence requires a paradigm shift not unlike what was needed when object oriented design was first introduced in the software community.  I would love to hear your thoughts related to this question.

You can learn more about how Essence can help to solve the problem that I talk about in the first two parts of the book at:

In future blogs I intend to share more about how this book evolved including a story related to how the book achieved its final title which was based on a  polling of many of my reviewers after I had literally written down more than 100 possible titles.  I will also share the top 4 candidate titles, and I will tell you why they all would have been great choices, and I will tell you now my initial personal favorite was not the final choice.

The book is available in ebook and paperback format from http://www.Amazon.com.  It is also available in multiple ebook formats from www.leanpub.com/15fundamentals, and www.apple.com/ibooks.

 

June 28, 2014

Critical Thinking and SEMAT’s Essence Framework

This past April I was asked to speak to a group of Computer Science students at Binghamton University, State University of New York, a school rich in a tradition of great software and systems engineering thinkers. In 1971, when I was working on my Masters degree at the same school, Jerry Weinberg (who was a professor of computer systems at the same school at the same time) published his book, “An Introduction to General Systems Thinking.” The book was reprinted twenty five years later on its silver anniversary and what intrigued me about this book when it first came out, and still intrigues me today is how it focuses on how humans think and solve real problems.

Fast forward to this past April, 2014. I find myself speaking to Binghamton University Computer Science students eager to understand the challenges they will soon face when they move into the world of industry and software development. Like I did in Medellin, Columbia last November, I decided to start by explaining a problem that the software engineering community faces today. I wanted to prepare them (and hopefully not scare them) for the real challenges they would soon face.

After the first 28 minutes of my talk, I then went on to explain how the new OMG standard, Essence, could help the software engineering community solve the problem I had been talking about.

Some of the topics that I address in this talk include:

Part I: The Problem We Face: Setting the Stage for Essence (28 minutes)

The Theory of Performance Improvement
Where We Go Wrong in Implementing the Theory
Insights into Two Types of Real Pain Points that Hurt Organizations
A Final Key Observation About Where We Go Wrong (before getting into Essence)

Part II: Essence: Helping to Solve the Problem (42 minutes)

What is Essence: “A Thinking Framework”
Key Elements inside Essence
Examples of how Essence Checklists Are Different
Representing Practices in Essence, and Why You Would Want to Do This
Explaining Common Practitioner Frustrations and How Essence Can Help
An Example of a Team Using Essence Activity Spaces to Self-Assess
Essence Competencies
An Example Scenario Courtesy of the Essence User Guide Volunteers
What if the Team Can’t Meet a Checklist Item?

At the conclusion of the presentation I came back to a few key points I made in Part I about two types of pain points that keep organizations from achieving and sustaining high performance and I reinforced a key related point about Essence.

This also brings me back to Jerry Weinberg. A great deal has changed in the last 40 years, but some things never change. In the end it is still about humans, how they think and how they solve real problems they face each day on the job.

My final point that I make in Part II of my talk to the students is about how Essence relates to critical thinking. Some of the challenges software developers face in today’s world are certainly different from those that Jerry was thinking about when he wrote his book in 1971, but the need for critical thinking in a world that is moving faster and faster has never been greater.

You can find both parts of my talk at Binghamton University on YouTube. Just google, “Paul E McMahon YouTube” and you should find the two videos;
“Part I: The Problem We Face: Setting the Stage for Essence” (28 minutes)
“Part II: Essence: Helping to Solve the Problem” (42 minutes)

Let’s keep this important conversation going. Love it or hate it, we want to hear what you think. Please provide your feedback through my blog (https://paulemcmahon.wordpress.com/ , the SEMAT blog (http://sematblog.wordpress.com/ , or the Linkedin SEMAT group.

Looking forward to hearing your thoughts.

November 23, 2011

What Does Lean Six Sigma and Semat Have in Common?

I recently went through an intensive ten week training course followed by a five hour examination to achieve my Lean Six Sigma Black Belt Certification.  Why I decided to invest the time to achieve this certification might not be why you think.   To help explain I need to first talk about another initiative I have blogged about in the past– Semat (www.semat.org).

I have been involved in the Semat initiative for almost two years.  Because all of us working on Semat are volunteers our progress has at times been slower than what we would like, but it is currently on the upswing.   For those who haven’t been following Semat closely,  we are building a kernel– or what we refer to as the “common ground”– for software engineering.  We realize we will only succeed if what we produce achieves wide acceptance.  Our current focus is on preparing our response to the OMG FACESEM RFP (A Foundation for the Agile Creation and Enactment of Software Engineering Methods).  http://www.semat.org/pub/Main/WebHome/Foundation_for_SE_Methods_RFP_ad-11-06-26.pdf.

Some have questioned the value of spending time on the Semat initiative.   As an example, I recently heard from a colleague who works for a largeUSdefense company that their OMG representative questioned the value of Semat because they didn’t see any “beef” in what we are doing.  If you attended our kernel working group meeting last Sunday you might understand this comment.  Last Sunday we initiated a high level review of our first seven kernel elements (Opportunity, Stakeholders, Requirements, Software System, Team, Work,  and Way of Working).

Small Semat sub-teams have been working  on descriptions, states and checklists for each of our kernel elements.  We are now stepping back and looking for consistency across these descriptions, and part of this effort includes building a small, but commonly agreed to, glossary.  One goal is for these kernel elements to be easily understood and to use a consistent vocabulary.  We plan to take our work out to the broader community to get more feedback.  This is critically important to ensure wide acceptance.

Just to give you an example from last Sunday’s discussion–  It was observed that in our initial kernel descriptions many words that were used seemed to by synonyms of others.  One example we discussed were the three terms– problem, obstacle and issue.  After lengthy discussion it was agreed that the way these terms were being used in our kernel description documents that  they were essentially intended to mean the same thing.  During this discussion it was also pointed out that the word issue, and problem often had a specific meaning inside certain organizations.

One of our goals is to try wherever possible to avoid terms that may carry certain baggage or lead to misunderstanding.   In this case we chose the term obstacle and initiated an effort to remove the terms issue and problem replacing them where it made sense with our preferred new glossary entry obstacle.   What we are doing should not be viewed as trying to ban words within Software Engineering.  We anticipate that specific organizations and specific software engineering segments will extend the kernel and its glossary to fit their needs.

What we seek is not to limit, but rather to provide a  small common ground starting point that we can all agree to.  To keep this small and consistent we spend an incredible amount of time in our working groups looking for things to throw out of the kernel, including words that that don’t add value or words that serve to confuse rather than clarify.  As a result, our goal could be viewed as eliminating “beef” that fails to stand up to our criterion of being universal to all software engineering efforts.

Now I can understand how some might question if it is really worth the effort to spend so much time worrying about these common everyday words we use.  Some might ask, isn’t our real goal to write high quality software?

The answer is yes, our goal is to write high quality software.  But those of us who have been working with software for a long time  have learned that the most direct path to high quality software requires that we first know our goal, second we must  know what must be done to achieve that goal, and third we must know how we will measure ourselves to determine if we have succeeded.

We have learned that not hitting our goal too often results from unclear objectives and conflicting stakeholder needs and expectations.  One way to help us address this frequent trouble spot is through a simple common language and small glossary of terms we can all agree to as a starting point.

I know it may sound trite, but when software efforts fail it still often comes down to the same issues it came down to 40 years ago — miscommunication of requirements and miscommunication of stakeholder expectations.

So what does all this have to do with why I invested time in becoming a certified Lean Six Sigma Black Belt?   Lean Six Sigma emphasizes the importance of first understanding where the pain is, or stated differently; What is the real problem we need to solve?  It second focuses on understanding the customer needs and how to translate those needs into critical to quality requirements which can me measured.  It next focuses on quick-wins and getting rid of waste.  To do this we make sure we understand each step of the process and how to distinguish value added steps from non-value-added steps specifically in the eyes of the customer.

Lean techniques drives an organization to look hard inside their operation not just at how to fix defects once they occur, but how to keep them from occurring in the first place.  Lean Six Sigma teaches us to look hard at our personal work habits, like cleaning up our work area making it easier to find what we need when we need it.   Last Sunday our Semat volunteers spent a good deal of time cleaning up the language we use to express what we do.  We are looking to eliminate non-value-added effort wherever it exists.  We are working to make it easier to communicate accurately the first time.

I didn’t decide to become a certified Lean Six Sigma Black Belt because I wanted to learn a new fad.  I did it because I wanted to learn something old that we all know, but too often forget.  Start by simplifying what you do.  Eliminate waste wherever you find it.  Eliminate anything that doesn’t contribute directly to your goal.  Where is the “beef” you ask?  Quality is not measured by how much beef we have.  It is measured by how much lean we have and whether our customers are delighted with the value they receive from our products and services.

Paul E. McMahon
Principal, PEM Systems

Author: Integrating CMMI and Agile Development

Certified Lean Six Sigma Black Belt

Phone: 607-798-7740
Web: WWW.PEMSystems.com

Email: PEMcMahon@ACM.ORG

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.