Are Agile and CMMI compatible?

First, I’d like to understand what does it mean to be compatible. Almost all articles I read explain how it would be possible to obtain a CMMI level 3 or 5 using Agile practices. But does been able to obtain a certification makes them compatible? I don’t think so. Obtaining a certification is not an objective per se, right? So how should we define whether they are compatible or not?

Agile’s objectives are to be able to improve business value, to increase performance and to increase quality. CMMI is a process improvement framework whose objective is to identify and evolutionary improve the processes of an organization. Based on both objectives, I believe being compatible should mean that CMMI can help an Agile organization improve its processes. Putting it in other words, would an agile organization benefit from using CMMI?

A question that I asked myself a few times is: If an agile organization uses a process improvement framework, should it be to improve its Agility? Well, something that we should not forget (although most of us do) is that being Agile is not an objective. It’s more like a requisite. It is also important to understand that Agility goes against standardization and also that it decreases as the size of the problem increases. Small organizations dealing with small problems (and less critical) can naturally be more flexible, more agile than bigger teams dealing with bigger problems. Standardization also comes at a price. Of course, it has its advantages such as leveraging the knowledge of the organization but flexibility and customization is lost. Those, I consider understandable reasons to loose Agility. What should not be lost is the philosophy, the set of values (as Jeff Patton says “Agile is a value system”). Therefore, if a process improvement framework is used in an Agile organization, it should share or at least respect the Agile values. Otherwise, the framework would be detrimental to the Organization’s Agility and this wouldn’t be for understandable reasons.

Does CMMI share the Agile values?

Presentacion Agiles 2010 - Que esperas de Agile?

http://prezi.com/4lmx1svobnxj/agiles-2010-que-esperas-de-agile/

Agiles 2010: Que esperas de Agile? on Prezi

Code Retreat Winchester 2010

Coderetreat Winchester 2010 from Enrique Comba Riepenhausen on Vimeo.

The Agile Effect

We are about to finish our second sprint and also the first month of the Agile Pilot project, here in beautiful Chiswick Park.

Pictures taken from http://www.virtual-chiswick.ukonline.co.uk/chiswick_park/

 
I again see the agile effect in place. Visibility, accountability, value delivering, enthusiasm, pride of work and trust are values where you see the effect immediately.


The process is completely transparent to all stakeholders. First, we built a story map which we have posted in our room. First thing all people see when they enter our room is our BIG STORY MAP.

Then, we all estimated how long the release was going to take. This came to a surprise to many, which were relying on magical estimations performed by .... Who knows, someone. Having to face a more realistic reality was harsh.

Progress is also very visible. Our progress is shown to everyone by means of burndowns and burnups. We also have a big taskboard, where all the team meets to discuss at various time during the day.

The effect continues and is very noticeable in the enthusiasm and the accountability of all team members. How is this enthusiasm triggered? I felt the same when I tried Agile the first time. I wanted to complete the tasks that I had assigned. I cared about our team finishing all stories that we committed to. And I felt that this responsibility came from inside. Nobody was telling me that I needed to complete this and this. And nobody is telling this team either. Yet, I can see everyone debating and trying to help to finish the stories.

I also can see how the lead time has been reduced by suppressing a chain link that didn't add any value, but it added time and confusion. Now the business owners talk directly with the team. This increases the probability of building the right product, it increases trust and it reduces time to market. The business owners are able to build the product they want and they can now trust that developers are doing their best to help achieve this. The developers are able to understand the business reasons behind the different decisions. They can see the purpose and they work knowing what the business owner will earn.

The Agile effect is immediate and is exciting to see!

Collect the data, analyze it, categorize it, act on the data

I just read in 3 different and not connected places, the steps that you should follow when dealing with information

1. In Jurgen's blog (http://www.noop.nl/2010/07/how-to-make-a-presentation-part-1.html), there is a post on how to create a presentation:
Step 1: collect topics
Step 2: create structure
Step 3: make story
Step 4: Define slides
etc.

2. In Dan Roam's book, when he describes the steps to work with a lot of information:
http://www.austinkleon.com/wp-content/uploads/2008/12/layitallout.gif

1. Collect everything you can
2. Lay it out where you can see it
3. Establish fundamental coordinates
4. Practice Visual Triage

3. In Ester Derby's and Diana Larsen's Retrospectives book

1. Set the stage
2. Gather Data
3. Generate Insights
4. Decide what to do
5. Close the Retrospective

Isn't it amazing?

Introducción a Test Driven Development(2)

Segunda parte de esta introducción a Test Driven Development

The Agile Objective

if you don’t know where you are going, any road will take you there (Lewis Carroll)

I believe the objective of Agile (or the objective of using the Agile approach to software development) is “being able to deliver customer value sustainably, with the required quality and in a changing environment”

Does the Agile Manifesto says this?

I believe it doesn’t, explicitly. However, aligning to the values and principles here stated leads to approaches to software development that have the customer needs as its main objectives. The Agile Manifesto is so value oriented that “uncovering better ways of developing software” means (to me) “uncovering better ways of delivering the value that customers need” (probably I read it this way because I am a software developer and delivering software is the only means that I have to provide value to them)

As I read the values again:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I become more and more convinced that everything points to delivering value. The first principle says processes and tools are a means to an end, not the objective. The objective is to deliver value. Documentation is not the objective. The objective is to provide software that brings value. Collaborating with the customers to build what the customers wants is more important that telling them that they didn’t know what they want. And building what the customer wants at that moment will deliver more and better value than building what the customer originally planned.

Following the principles and values, we build software:

• that contains the features that the customers are looking for
• where the most important features are delivered early, to make our customer competitive and to solve their problems faster
• that adapts as the business circumstances change
• and that contains the required quality that allows the product to deliver value

As a conclusion, the Agile Manifesto didn’t set an objective but it did set a direction and it also set the bases for a definition of building software focused on delivering value. Not focused on technology (our focus, geeks) or plans (project manager’s focus) but on customer’s needs. The objective (at least what I understand as the objective) is a direct consequence of following these values and principles.

Going back to my definition...

I mentioned the words “sustainably”, with the “required quality” and “in a changing environment”. I will try to explain why these words are in my definition.

There’s a common misconception, usually among people that are just starting with Agile, who believe that Agile means just throwing some code out there fast, without having to think about the design and without having to maintain any documentation. I believe this misconception should be addressed as soon as possible: in the definition of the objective. Having to think about sustainability since the beginning, forces you to think about keeping the cost of change low, which forces you to think about automation and maintaining the code base in a good state. The technical leg of Agile is very important in supporting sustainability because we should be able to deliver value to our customers for as long as they need, without having to be more and more expensive.

With the required quality... That is arguably part of the objective. Some might say that if the software doesn’t have the required quality, it won’t deliver the required value. As you probably know, quality can be divided into external quality “extrinsic, as perceived by the final user” and internal quality or technical quality which allows the product to be reliable, adaptable and ultimately to deliver sustainable value. So which is the required quality? It is the quality deemed to be enough by the Product Owner to deliver the value it needs in the market plus the quality needed by the technical team to being able to keep delivering value.

Finally, in a changing environment. And the business world is a changing environment after all, right?. Who has time to freeze the requirements for a year and be competitive at the same time? It seems to me that Waterfall always pointed to a different direction than business (This may be the reason of so much failure in our field?). Agile is designed to fit in changing environments. And of course, it works better than Waterfall in changing environments. It is one of its distinctive characteristics. Our process and our technical practices should be thought out to make us competitive, to be able to adapt by producing adaptable and reliable software.