The realities of trying to do Agile in a CMMI environment

Outsourcing is hard. Trying to do agile in a Capability Maturity Model Integration (CMMI) level 5 environment is damn near impossible. Without even discussing lean, let’s start by getting the basics down and first examine how one can start thinking about doing Agile with SCRUM in an enterprise development before tackling outsourcing. CMMI defines the what, whereas Agile lets you in on the how. This blog post aim to highlight some of the challenges you will face when bundling Agile with CMMI. To help stay the course and hit the ground running, a simple summary of my key takeaways based on previous experiences are provided. Most importantly, go sit the Scrum Master/Product Owner training. It is worth the 2 days.


The assumption here is most people get CMMI wrong. A quote from the father of CMM, Watts Humphrey, “Work on you quality and processes first, the levels will come by themselves.” This by nature is agile, an implicit continuous improvement if you will. Unfortunately, the pursuit of certification has landed most adopters and practitioners of CMMI into the Waterfall model as we understand it today. As an interesting side note, the Waterfall model since its conception is not, nor has it ever been a single rigid software development life cycle. Most people misunderstand it and simply ignored the rest of the paper after the abstract, see “The art of destroying software.”

For me, CMMI level 5 conjures up an image of Jedi masters/ninja coders, industry thought leaders that are constantly optimising, learning, sharing, and challenging the status quo. My experience thus far is the exact opposite. Unfortunately for me, CMMI level 5 has been an environment with large amount of unnecessary restrictions, heavyweight processes, meetings, coupled with documentations that nobody reads or maintains. Worst case scenario is that useless documentation exists where nobody understands the content. Let’s not even begin to explore the notion of devops or fullstack as CMMI is a siloed model that ties everything together through processes, and you guessed it, meetings. A quote from a man I respect very much once said, “Meetings keep you busy, and not spending money.” The reality is that CMMI is typically completely wrongly applied, but complacency or fear of change makes CMMI the prime roadblock for doing anything Agile. In a devops world where Agile is considered way too heavy, CMMI appears to be out of the stoneage.

An interesting fusion of both CMMI and Agile started to surface nearly half a decade a go. Supported by some academics, CMMI is slowly incorporating and adapting to Agile. However, the practical aspect of transforming a rigid siloed team into a some what agile setup is a monumental shift in paradigm, all too often hampered by organisational pushback. CMMI is not going to catch up anytime soon as it continues to waddle in the back of the bus with its late adoption of Agile. Currently CMMI 1.3 for development has incorporated Agile into the processes. Services and acquisition has been left outside alone (it’s cold out here). Overall, one does not have to look very far to get a sense of the magnitude and complexity of CMMI 1.3.

The Agile Manifesto: the values

Let’s take a breather from CMMI and rehash the Agile Manifesto. Hark! Let us ask in their wisdom.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Agile Manifesto: the principles

The following are the principles of Agile. Truth to be told that it is arguably easier for startups or development houses to be Agile than enterprises. Limited budget and human resources usually breed clever ways to address ever changing requirements. Light organisational structure also helps. However, the bottom line is that Agile principles are the same regardless of budget and team size. These principles are proven and battle hardened and are well suited for both large or small organisations.

  1. Satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  2. Business people and developers must work together daily throughout the project.
  3. Build projects around motivated individuals.
  4. Give them the environment and support they need, and trust them to get the job done.
  5. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  6. Working software is the primary measure of progress.
  7. Agile processes promote sustainable development.
  8. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What the Agile doesn’t tell you – key takeaways

All agile methodologies will help highlight the pain points quick and early. However Agile is not the silver bullet for solving these pain points, it is up to you to address them still. The real difficult barriers are usually organic, organisational, and cross-functional.

Expect change. A lot of changes. This is the essential first step towards lean, and it is going to be a painful one for some. On a positive note, being fluid and adopt to change is all part of being Agile.

Juggling SCRUM with regular traditional project management status updates will be tricky. Try Commitment-Driven SCRUM. See Commitment-Driven SCRUM.

CMMI usually requires a fixed price contract based on some fixed estimation. In order to correctly estimate the work involved, the type of tools, platforms will be rather monolithic and probably inflexible. New technologies are not part of the CMMI game. This is the exact opposite of Agile. Though CMMI is suitable for certain application domain, it is important to find the balance and not let CMMI swallow up every facet of I.T. Marketing and sales would rather have new prototypes instead of a mini ERP.

Lastly, Agile does not dictate what methodology best fit your organisation or team. Remember, the team should pick their own methodology appropriate for how they wish to work and interact.


If outsourcing is part of the gig, have a read the following 3 part blog series on outsourcing and SCRUM I wrote nearly two year ago. It is still applicable today.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s