By Matt Gelbwaks, Globant´s Chief Agilist 

Hi! Perhaps you came here either by shear accident (whoops – hit the back arrow), or because you wanted to know what software development meant to us. Well, great, cause that is what we thought we would do on this page! When buying services, organizations look to standards and methodologies to understand how providers think and work. We know standards. Many apply to us and we comply with many! But really, what do these standards mean to you? Sometimes, there are misunderstandings as to what the alphabet soup of acronyms really mean and in the ensuing confusion, the wrong traits are honored and buyers remorse sets in once the impact of the decision is discovered. Let me explain a little more.

Part 1 – the CMMI

Many organizations now require that their services vendors comply with CMMI level 3, 4, or even 5. This is viewed as a minimum standard to ensure quality performance against a contract. Many of the same organizations are then really disappointed in how their efforts turn out. Different organizations feel the need to require the CMMI requirement for different reasons. Some require it because they too are mature in their processes, but all too rarely, do these disappointed organizations conduct root cause analysis to understand the reasons for their disappointment in the way their subcontractors have performed.

Now, I bet you are wondering from where I think the disappointment stems. Certainly, anything I say will be a gross generalization, but never being shy of generalization, let’s lunge forward!

I think we need to start at the SEI – There are a lot of misconceptions about this. First, it really is not a standard. It is a model or a framework that describes a process improvement approach. So if you are compliant with the CMMI, then you are in a much better position to be able to improve your development processes not necessarily your software product. This difference is kind of subtle, but what it specifically provides is:

[an approach that] can be used to guide process improvement across a project, a division, or an entire organization. … [Following the] CMMI best practices enable organizations to do the following:

• more explicitly link management and engineering activities to their business objectives
• expand the scope of and visibility into the product lifecycle and engineering activities to ensure that the product or service meets customer expectations
• incorporate lessons learned from additional areas of best practice (e.g., measurement, risk management, and supplier management)
• implement more robust high-maturity practices
• address additional organizational functions critical to their products and services
• more fully comply with relevant ISO standards

Quoted from the SEI: http://www.sei.cmu.edu/cmmi/general/index.html

I imagine most of the organizations that are disappointed in the performance of CMMI level X partners are disappointed not because they recognize these partners are better able to improve themselves than other non-compliant organizations, but rather because assessed or not, their goals, objectives, and expectations are still not being achieved.

With any partnership, the most important aspect is that expectations are met. Unfortunately, the CMMI, at no level, guarantees that expectations will be met.

Part 2 – Agile
Agile seems to be the hottest thing in methodology so far this century. It has a lot of bad press and a lot of hype, so people are certainly justified in carrying a healthy does of skepticism when they consider it as a development approach. To start with, Agile, like CMMI is also a Framework, but rather than being a process improvement framework, it is a development framework. Interestingly, it includes some process improvement inherent in its methodology, but it is not merely focused on that. So, really, what is Agile?

Agile is the framework, agile is a noun. The noun suggests a methodology that is nimble, that can change and accommodate change. Quick brown foxes are agile. They can get the goose and they can get it home to all the little pups too – but they don’t do software! Agile, we have coined, has a number of practices that describe how the approach works. A point to remember here is that there are no hard and fast rules and there are a lot of ways to be agile in development. The practices are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. From the Agile Manifesto: http://www.agilemanifesto.org Two chief points to reiterate here are Simplicity and Satisfying the Customer. The latter point, which is actually the first practice is what allows us to meet customer expectations. The former reflects the complexity in both execution and approach often times obfuscates intent. Kidding aside, customers are often most satisfied with the elegance of simplicity in that a simply working system quickly is more useful than the one complex one that is tough to understand and to maintain. Note the last practice – this is the integrated process improvement, and this is what leads us to Part 3 – Agile within the CMMI

Part 3 – Agile within the CMMI
Much of the early literature was awash with how Agile and CMMI could not possibly be convergent. We think that this mostly stemmed from people trying to fit both these ‘things’ in the same box. As we have stated above – they are different. One is a framework for process improvement, one is a development philosophy. Agile fits within the constructs of CMMI (testament to this is the number of Companies that practice Agile who are CMMI level 3 or above).

Within each level of the CMMI, there are goals and practices. For each of these there are approaches you can use that are consistent with Agile methods and there are approaches that are not. Sometimes, though, we have become so schooled on seeing implementation of practices in non agile ways that we miss the inherent simplicity that we can bring to bear on the process allowing us to be both compliant and Agile. An example:

The very first practice in Level 2 is Requirements Management. The very first goal in the very first practice is:

SP 2.1.1.1 Obtain an Understanding of Requirements.

Traditionally, we see this as the development of a comprehensive document called a System (or Software, depending upon layer) Requirement Specification (SRS) and traditionally the Assessors look for evidence that these documents are written and maintained with the view that accumulating knowledge of the requirements in a compendium demonstrates understanding, and it does.

However, in many Agile methodologies, we write stories in the Customer’s own lexicon and have the customer acknowledge back a validation that these stories encapsulate their need, hence this too demonstrates understanding of requirements.

In traditional methodologies, the SRS is completed and then signed off by the customer prior to development starting. In Agile approaches, we do the stories one at a time – write approve develop, write approve develop. Both are valid approaches and both are consistent with the intent of the CMMI framework. One tends to be a little simpler in execution.

We can progress through the entire framework and examine each and every goal and practice. None of them specifically preclude and agile approach, but many require alternative perspective and an open mind.

With a convergent process, products are improved. As we improve our products we are also able to better satisfy our customers. It is not sufficient to merely meet customer’s expectations, unfortunately, because through years of poor project performance on all measurable axes, our customers expectations have been set quite low.

Therefore, we challenge all of you to both meet their expectations and begin to raise them using Agility within the CMMI to achieve satisfaction and to go beyond!

top ▲