Is the Process and Product Quality Assurance Process Area compatible with Agile?

This is a special post number 50!! So....

Enough, let's go back to Agile and CMMI compatibility..

Introduction

The Process and Product Quality Assurance Process Area, a process area at maturity 2, aims at objectively evaluating projects for adherence to the standards processes and procedures. Objectivity is key. It can be achieved through an external group or through demonstration of objectivity.

Below are the specific goals and practices:

SG 1 Objectively Evaluate Processes and Work Products

SP 1.1 Objectively Evaluate Processes

SP 1.2 Objectively Evaluate Work Products and Services

SG 2 Provide Objective Insight

SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues

SP 2.2 Establish Records

Is it compatible?

This process area aims at ensuring that each of the projects in the company follows the company’s defined processes and practices. Something that can make this process area difficult to apply in an Agile company is the empiricist nature of Agile methodologies. In one side, there’s a company defined methodology (and the willing to follow it represented in this process area) and on the other there’s the Agile encouragement to introspect on the methodology and modify things that are not working. Probably this goes back to the advantages and disadvantages that I mentioned in the introduction to this series of posts and also to the fact that Agile is a value system. Therefore (and again), probably it’s more important to ensure that the company’s values (which in an Agile company should be compliant with the Agile values) are followed than to ensure that a specific defined process is followed step by step.

Another thing I also wonder is what is the best mechanism to provide this insurance.  The CMMI reckons that “Traditionally, a quality assurance group that is independent of the project provides this objectivity.”. However, it also states that “It may be appropriate in some organizations, however, to implement the process and product quality assurance role without that kind of independence. For example, in an organization with an open, quality-oriented culture, the process and product quality assurance role may be performed, partially or completely, by peers; and the quality assurance function may be embedded in the process.”. I believe that the second mechanism should be the one recommended in Agile environments. A mature Agile team is one that doesn’t of any external group to follow the processes and practices and that realizes when it’s incurring in technical debt and can recover and pay it. How does it get there? Through a leader embedded in the project. A leader is a software craftsman that teaches the rest of the group the practices and ensures that they are always followed, even in tempestuous times (when the only thing that matters is handling some software by the door!)

Conclusion

Exact adherence to processes shouldn’t be encouraged in Agile environments, but exact adherence to values should. The best mechanism to ensure quality are through leaders embedded in the projects that act as quality and process keepers. 

  
Other Process Areas

- Is the Measurement and Analysis Process Area compatible with Agile?

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?

Is the Measurement and Analysis Process Area Compatible with Agile?

Introduction

The measurement and Analysis process area, a process area at maturity 2, aims at developing a measurement capability that is used to support management information needs. Measurement objectives based on identified information needs are defined and using these objectives, objective and quantifiable measures are defined. Mechanisms to collect and store the data should also be defined.

Below are the specific goals and practices:

SG 1 Align Measurement and Analysis Activities

SP 1.1 Establish Measurement Objectives

SP 1.2 Specify Measures

SP 1.3 Specify Data Collection and Storage Procedures

SP 1.4 Specify Analysis Procedures

SG 2 Provide Measurement Results

SP 2.1 Collect Measurement Data

SP 2.2 Analyze Measurement Data

SP 2.3 Store Data and Results

SP 2.4 Communicate Results

Are they compatible?

Agile possess a culture of continuous improvement, through continual inspection and adaptation. The concept of Kaizen, that comes from the Lean world is also very popular. The question is ‘how is this improvement attained?’ and ‘is it always aligned with the wider company objectives?’.

How is this improvement attained? How should be the process to improve? The mechanism suggested by CMMI is the only one I know. The objective is identified, measurements that tell us if the objective has been reached as well as a plan to get there are defined and then successive measures are taken through the path. Having a company wide process improvement framework like CMMI can help identify these objectives in a project more easily and also assures that the objectives selected are aligned with the wider company objectives. It can also help define the measures, which should be “precise, quantifiable measures”.

However, I have a couple of concerns related with setting objectives and trying to reach these objectives:

1. Not weighting properly the importance of the objective within the whole context of the project

Let me picture this with an example, for which I will use Highsmith’s Agile triangle.

We may set up our objective as “Improve prior levels of quality” (taken from the CMMI examples). What is a quantifiable precise measure for this objective? Probably most will say counting the number of raised bugs. Having no bugs is really wonderful, but having no bugs on a software that doesn’t do what the customer needs is really valuable?

2. Creating dysfunctional behaviours

The human beings find ways to reach the objective that don’t match exactly what the objective was created for. Having raised less bugs assures us that the software is more robust? Are we really doing things better? The human/social aspects could be tricky.

Another thing to keep in mind when devising measurements and processes to be used inside a project is that all these processes and measures are “waste” (things that don’t add value to the product). Of course, this could all be good waste, because it will allow the company to improve, to do things better in the future. Nonetheless, they should be treated as such and designed to be as light as possible. Probably, automation (again) is the key in this regard.

Conclusion

I believe that creating more formal mechanisms to improve, that are aligned with company objectives, could be beneficial to Agile projects which in general focus their improvements efforts informally and with a project scope. The real objectives and the human aspects should be taken into consideration to avoid optimizing in the wrong side. The improvements processes should be light and agile.


Other Process Areas

- Is the Requirements Management Process Area compatible with Agile?
- Is the Project Monitoring and Control Process Area compatible with Agile?
- Is the Project Planning Process Area compatible with Agile?

Is the Requirements Management Process Area compatible with Agile

 Introduction

The requirements management process area, a process area at maturity 2, deals with managing all requirements related to the project throughout its life.

Below are the specific goals and practices:

SG 1 Manage Requirements

SP 1.1 Obtain an Understanding of Requirements

SP 1.2 Obtain Commitment to Requirements

SP 1.3 Manage Requirements Changes

SP 1.4 Maintain Bidirectional Traceability of Requirements

SP 1.5 Identify Inconsistencies Between Project Work and Requirements

SG 1 Manage Requirements

The only objective in this process area states that requirements should be managed by doing the following:

• Managing all changes to the requirements
• Maintaining the relationships among the requirements, the project plans, and the work products
• Identifying inconsistencies among the requirements, the project plans, and the work products
• Taking corrective action

All of this is completely true in an agile environment. However, the practices recommended to get there is very different. Let’s analyze each of the practices.

CMMI lists the following as the recommended practices to manage requirements:

1. Obtain an understanding of the requirements. When and how complete? Well, the objective states that “The project maintains a current and approved set of requirements” so my assumption is this understanding is complete.
2. Obtaining commitment to Requirements. From those “who have to carry out the activities necessary to implement the requirements.”
3. Manage Requirements Changes. Analyze impact and document rationale.
4. Maintain Bidirectional Traceability of Requirements. From requirements to source code and vice-versa. This traceability helps determine requirements have been completely addressed.
5. Identify Inconsistencies Between Project Work and Requirements.

Requirements are managed differently in Agile. Let’s see how the practices would change:

1. The project backlog doesn’t represent a current approved set of requirements. Requirements in a backlog have different levels of understanding and approval. Requirements live their life in the backlog with different levels of understanding and approval. They are born as ideas, “topics of conversation” and grow their understanding and approval, even after they are implemented. The driver in this understanding is their priority. More important requirements need to be understood/approved first. There could be phases in the form of releases in the backlog that will determine the understanding and approval of a set of requirements.
2. It is important the Agile recommendation of having cross-functional teams. A jelled team which contains all the necessary expertise represents the easiest path for full commitment.
3. Changes in the backlog should be managed lightly, but continually. In fact, I am not even sure that they should be named changes. As previously mentioned in point 1, a requirement grows in the backlog, perhaps changing its status, form and priority. This doesn’t mean that Agile embraces high volatility or churn. All stakeholders should be aware of the impact of the changes. A change may be important, but is never free. The Product Owner, responsible for the ROI is the one to make the trade-off.
4. Maintaining traceability could be very time consuming and only helps determine that requirements have been addressed. Acceptance Tests are less time consuming are help determine that requirements have been fulfilled.
5. Again, automated acceptance tests are the recommended practice to detect and fix inconsistencies in an Agile project. Doing this manually would be too time and mind consuming. Computers should maintain all this knowledge gained and detect the inconsistencies for us. The second recommended practice is to involve the customer through all the project. Customers are the best persons to detect inconsistencies (should we call them inconsistencies?)

What is missing in the recommended practices?

Prioritization: One of the most important aspects in managing requirements in an agile environment is managing priorities. Prioritization works starts at project inception and follows throughout the project. Of course, this is a very difficult task as it involves not only understanding the business value that different requirements add but also making trade-offs based on technical feedback and measures of effort.

Requirements live and Requirements light: One of the most difficult and time consuming tasks during a project is to maintain requirements up to date. If doing this is too time consuming, agility suffers. Many agilists suggest that the best way of maintaining them is through maintaining them as executable requirements (or executable specifications, examples, etc.). An executable requirement must be maintained and it always up to date. Being able to execute/debug this requirements allows to easily trace requirements with source code.

Conclusion

I believe the only goal of this process area is entirely applicable in an agile environment, but the path to get there goes in a complete opposite direction. The CMMI recommendation is to get a complete approved set of requirements, which is maintained and traced to the source code (and viceversa) throughout the life of the project. The agile recommendation is to maintain a prioritized executable specification at all times. The later mechanism is lighter, assures is up to date and automated.


Other Process Areas

- Is the Project Monitoring and Control Process Area compatible with Agile
- Is the Project Planning Process Area compatible with Agile?

Is the Project Monitoring and Control Process Ares compatible with Agile?

Introduction

The Project Monitoring and Control area, a process area at maturity level 2, aims at understanding the project’s progress and taking corrective action when the project’s performance deviates significantly from the plan.

Below are the specific goals and practices:

SG 1 Monitor Project Against Plan

SP 1.1 Monitor Project Planning Parameters

SP 1.2 Monitor Commitments

SP 1.3 Monitor Project Risks

SP 1.4 Monitor Data Management

SP 1.5 Monitor Stakeholder Involvement

SP 1.6 Conduct Progress Reviews

SP 1.7 Conduct Milestone Reviews

SG 2 Manage Corrective Action to Closure

SP 2.1 Analyze Issues

SP 2.2 Take Corrective Action

SP 2.3 Manage Corrective Action

SG 1 Monitor Project Against Plan

This goal states that there should be a way to compare actual performance, against what was established in the plan. Among the things that are measured are project planning parameters,  commitments, risks, stakeholder’s involvement, progress reviews and milestone reviews.

I believe in Agile, there is a shift from traditional management in who does the monitoring, how it is performed, what is measured and also in the objectives of the monitoring. These changes should be reflected in the process maturity framework.

First, who does the monitoring and and how it is performed? In Agile, this is the not the responsibility of the Project Manager, but of the entire team. Agile has 2 main practices that enable monitoring that are very effective because they encourage self-organizing teams (increasing accountability and enthusiasm as a side effect). The first enables day to day monitoring and is called Scrum daily meeting if you come from the Scrum world or standup meeting if you come from the XP world (though in Argentina, most of the people call it “the scrum”). In this meeting, the team as a whole “monitors” how it is doing with the tasks, which are the blocking issues and how is the iteration progressing. It is important to stress that there isn’t a central authority to report to in this meeting. It is strictly a team’s meeting. The second monitoring meeting practice is the retrospective. This meeting happens after each iteration and enables to monitor how the team performed in the iteration and so far in the project. This meeting allows for a more thorough “monitoring” or introspection as we like to call it and bigger corrective actions can be taken. Another practice suggested for monitoring is the use of Visual Radiators which allow anyone to constantly monitor the project’s progress.

What is measured? As the Project Planning process area suggests an activity based project plan, the project monitoring suggests to monitor “the activities and milestones”. As previously said, Agile does not encourage activity-based plans. Basically, work products that don’t deliver business value aren’t really considered progress in Agile terms. So what should be measured? Certainly, the best measure of progress is to be able to measure how much business value has been delivered. Although this is really difficult (and I must confess I’ve never done it), there are techniques that allow to monetize the value of the features (see Value Point Analysis in Highsmith's Agile Project Management book). Another measure is effort, but it should be stressed that progress is made when running, tested and customer accepted features that deliver value are completed. Progress should be tangible. Intermediate work products don’t represent progress.

Finally, what about the objectives? A successful project is not one whose measures match the plan, but the one that delivers the value expected by the customer. Bjarte Bosgnes, in Implementing Beyond Budgeting asks a simple question, “What is the best performance: delivering 100 against a target of 100, or delivering 105 against a target of 110?”. Most people would agree that 105 is better than 100, however most performance measurements systems would call 105 against 110 target a failure [from Agile Project Management]. As Highsmith states in his book, I believe an agile process maturity framework should shift its objectives from the constraints (scope, schedule, cost) to delivering value.

There is another topic within this goal that I would like to tackle. CMMI suggests to record actual parameters to be used as historical data. Something I am afraid of when measuring actual parameters (actual times) is to use them as a pressure mechanism. I believe that measuring actual times of taks and comparing them to estimated times lead to dysfunctional behaviours that damage the project (like overestimation or cutting corners - dropping quality - to achieve those times)

SG 2 Manage Corrective Action to Closure

The second objective states that corrective actions should be managed to closure when project’s performance or results deviate significantly from  the plan.

What does it mean that corrective actions are “managed” to closure? It means there is a manager that assures that the actions take place. How do we get that assurance in Agile, inside a self-organizing team without a manager per se? People inside the team should be hold accountable for leading the corrective actions to closure. This, in my experience, is sometimes difficult as the informality of the process sometimes leads some people to not take the corrective actions seriously (specially in less mature teams, previously used to command and control structures). However, as CMMI states, corrective actions should be closed and there should be a mechanism that forces the team to do so.

Conclusion

Monitoring and taking corrective actions are necessary within any project. The way CMMI suggests to do it seems very oriented to traditional project management. Agile project management takes a big shift in what is measured, how it is measured and in the objectives of measuring. This should be reflected in the process maturity framework to be compatible with Agile.

Is the Project Planning Process Area compatible with Agile?

Introduction

The Project Planning area, a process area at maturity 2, aims at establishing and maintaining plans that define project activities. To construct a plan, the requirements need to be determined and estimated and with this information, a documented plan that stakeholders can commit to should be built.

Below are the specific goals and practices:

SG 1 Establish Estimates

SP 1.1 Estimate the Scope of the Project

SP 1.2 Establish Estimates of Work Product and Task Attributes

SP 1.3 Define Project Lifecycle

SP 1.4 Determine Estimates of Effort and Cost

SG 2 Develop a Project Plan

SP 2.1 Establish the Budget and Schedule

SP 2.2 Identify Project Risks

SP 2.3 Plan for Data Management

SP 2.4 Plan for Project Resources

SP 2.5 Plan for Needed Knowledge and Skills

SP 2.6 Plan Stakeholder Involvement

SP 2.7 Establish the Project Plan

SG 3 Obtain Commitment to the Plan

SP 3.1 Review Plans That Affect the Project

SP 3.2 Reconcile Work and Resource Levels

SP 3.3 Obtain Plan Commitment

Let’s analyze the compatibility of each goal

SG 1 Establish Estimates

This specific goal states that there should be a way of estimating project planning parameters needed to perform the necessary planning, organizing, staffing and budgeting. Factors typically considered are: project requirements, scope, identified tasks, technical approach, etc.

I believe it is very important in Agile as well to be able to provide initial estimates that allow the project to be resources and funded. There are techniques like Story Mapping and planning poker that can be used to provide an initial estimate of the effort needed to complete the project.

There are 3 points that in my opinion should be mentioned in this goal to be more compatible with Agile:

1. Estimations are rough at this point in the life of the project: I believe it is of no value to spend more time trying to refine them. There is a useful concept called the cone of uncertainty that illustrates how estimations become more accurate as the project progresses (i.e. as more is known about what needs to be estimated)


2. Maintain the estimations is really important: Mike Cohn called his book “Agile Estimating and Planning”, because in Agile this is an activity that is performed continually throughout the life of the project. It is of more value to provide rough estimates at the beginning and then update them (and of course re-plan based on the new ones) than trying to be accurate when there is no enough information.
3. Committing to estimations can create dysfunctional behaviours: SG 3 states that the stakeholders will commit to the plan created based on these estimations. If the people in charge of the estimations will be penalized for their estimations, what ends up happening is they tend to buffer their estimations, providing the more pessimistic numbers. I have a personal experience in a CMM5 level organization, where we needed to provide estimates and we were penalized if the estimations differ on -25%/+25%. Of course they never did, because we buffered all the estimations and then worked slowly and with time, as our estimations forced us.

SG 2 Develop a Project Plan

A project plan is a formal, approved document used to manage and control the execution of the project. It is based on project management requirements and estimates. The plan should include the budget and schedule, should identify risks, should plan for needed resources and skills and finally for the stakeholder involvement.

There are 3 points that I believe are worth mentioning with respect to Agile plans:

1. A good plan should prioritize work according to the features that provide more value: This is the best way of minimizing risk and improving the ROI. A project sliced in incremental releases enables customers to receive the features they need the most sooner. This possibility is one of the great advantages of Agile and I believe should be reflected in the way CMMI suggests to build the plan.

2. The plan should be light: Agile embraces change. Adapting to change requires that products artifacts are changeable. The codebase should be easy to change and the coordination artifacts (like the plan) as well.  

3. The plan should not be activity-based: Mike Cohn explain in the 2nd chapter of “Agile Estimating and Planning” that one of the reasons that traditional planning fails is that planning is based on activities rather than on delivery of features. Cohn states that activities-based plans have 3 disadvantages:
- “Customers get no value from the completion of activities”
- “When we review a schedule showing activities we do so looking for forgotten activities rather than for missing features”
- “Further problems occur because activity-based plans often lead to projects that overrun their schedules. When faced with overruning a schedule some teams attempt to save time by inappropriately reducing quality.”

SG 3 Obtain Commitment to the Plan

“To be effective, plans require commitment by those responsible for implementing and supporting the plan.” says CMMI.

I believe this is the most incompatible objective in the area. Commitment to a plan? What if changes are needed? Having to obtain a formal commitment to a plan indicates a lack of trust in the organization. People committed to a plan will probably fail to deliver the best value, as they may be committed to outdated objectives. People need to be committed, but I doubt that obtaining this commitment formally and to a plan is the best way of obtaining commitment.

Conclusion

While it is important in Agile to be able to provide estimations, build a plan and commit to it, I have my concerns that having to fulfill the CMMI objectives forces Agile teams to provide plans that have more information than needed, put more effort on the estimates than what provides value and create dysfunctional behaviours. Planning and plans are important, but they are just a tool in our objective, which is providing the value the customers are looking. Plans built with too much uncertainty don’t have any value and neither forcing people to commit formally to them.

Would the process capability levels fit an Agile Environment?

In CMMI, the scale to measure a process capability is divided into 5 levels: performed, managed, defined, quantitatively managed and optimizing. Do these levels make sense inside the Agile world? Would this be the improvement path that an Agile organization should follow to improve its processes? Is the scale compatible?

Let’s look at the 5 levels:

Performed Process

“A performed process accomplishes the work necessary to produce work products”. The first level falls outside any approach, so it’s pointless to analyze it.

Managed Process

A managed process “is planned and executed according to policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.”. The key difference with respect to a performed process is that the managed process is planned and then measured, having the possibility of taking corrective action “when the actual results and performance deviate significantly from the plan.”

What would it be a managed process inside an Agile environment? Well, basically I believe there are no managed processes, at least not in the way suggested here which distills a command and control project management mentality where management means “monitor, control and take corrective action”. This type of management is in the heart of CMMI (Prof. Judson Neff says “the only way to manage complex operations is to manage, to detailed and precise plans”). Agile, on the other side, relies on another type of management. One that sets the limits and get the resources, but that allows the team to self-organize to accomplish the work. It relies on a management that uses leadership to manage. Well, probably it’s just my view because nowhere does it says that a project manager is the one that monitors, controls and take corrective action (does it?). It is important nonetheless to stress that the process should be managed by the team, which should be the one that plans, monitors and take corrective action if necessary.

Defined Process

“A defined process is a managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes work products, measures, and other process improvement information to the organizational process assets”. This level is where standarization/institutionalization comes in. Projects learned from the organization standards, and the organization learns from the projects as knowledge goes both ways.

I believe that besides having defined processes, an organization would benefit from having a defined set of values. For example, I think that an organization may have a process to gather requirements from customers. As important as the process itself is that everyone believes that having constant communication and collaboration throughout the project is vital to success. Another example that I can think is that of technical excellence. I believe that more important than having a defined process for developing is having the mentality of a software craftsman and understand why technical excellence is so important (why doing automated tests, clean code, etc.).

Agile was described for the first time as a set of values, and it is this set of values what guides agilists. Having these values defined and clear inside the organization is probably of more value than having the exact process definitions. I know it does sound unrealistic, as having a repository of values probably doesn’t make a lot of sense. Probably values live more on the tacit knowledge of the organization and they are more like a human asset. Well, Agile is more about people than about processes after all...

Quantitatively Managed Process

“A quantitatively managed process is a defined process that is controlled
using statistical and other quantitative techniques. The product quality,
service quality, and process-performance attributes are measurable and
controlled throughout the project.” Measuring and statistically analysing allows to identify the special causes of variation and prevent its recurrence.

There are 2 things that I am afraid to, when measuring the processes. First, something that stayed firmly in my mind after reading Highsmith’s book: Value over constraints. It’s far more important to measure, or at least to understand, how  much value a certain process provides than to measure and optimize for the constraints. A team worried by meeting objectives related to constraints is at great risk of generating dysfunctional behaviours which decrease the value that the team is able to generate. The second thing that I am afraid of is relying only or too much on numbers and measures. I know from an organization perspective (broad perspective) understanding what works and what doesn’t in terms of numbers is perhaps the only way to know what’s working and what isn’t but my experience in development teams says that common sense and team feeling are also important, not measurable and equally important. I guess I am reluctant to believe that everything in a human intensive task such as developing software can be quantifiable.

Optimizing Process

“An optimizing process is a quantitatively managed process that is changed and adapted to meet relevant current and projected business objectives. An optimizing process focuses on continually improving process performance through both  incremental and innovative technological improvements.                              Process improvements that address common causes of process variation, root causes of defects, and other problems; and those that would measurably improve the organization’s
processes are identified, evaluated, and deployed as appropriate.”

A couple of thoughts came to my mind after reading the CMMI optimizing process level: First, it seems to me that the definition is geared towards a production environment, not a development one. Variable results are good in development, when knowledge is formed and not good in production. Second, it is weird to me that the idea of optimizing comes only in the last level coming from the Agile world, where introspection and improvement are performed since the very beginning (at a very intuitive level). On one side, it makes sense because to be able to optimize, you need to have a managed process and be able to measure/quantify what needs to be improve. On the other, leaving the optimize mentality until the last level could be harming (in my opinion). Finally, nowhere does it say that the optimization is to be able to produce more value for the process, which I think should be the first objective. Probably, in other engineerings or in manufacturing, optimization is performed to decrease variation or find root causes for defects. In software development, where variability creates knowledge, this is not entirely true.

Conclusions

I believe that intuitively, the capability levels are compatible. The first improvement from not doing anything is that the process is managed, i.e plan and monitor to take corrective action. Doing it in an Agile way, it should be managed by the team. Then, there is institutionalization. I believe that the institutionalization of the Agile values is equally important than institutionalizing the processes. Then, there is understanding how good or how bad the process is working and optimizing it. The most important, but probably most difficult thing to quantify is how much value the process provides. Also, something to keep in mind is that software development is very different than doing manufacturing.

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!