Is the Technical Solution Process Area compatible with Agile?

Introduction

The Technical Solution, a process area at maturity level 3, aims at designing, developing and implementing solutions to requirements.

Below are the specific goals and practices:

SG 1 Select Product Component Solutions

SP 1.1 Develop Alternative Solutions and Selection Criteria

SP 1.2 Select Product Component Solutions

SG 2 Develop the Design

SP 2.1 Design the Product or Product Component

SP 2.2 Establish a Technical Data Package

SP 2.3 Design Interfaces Using Criteria

SP 2.4 Perform Make, Buy, or Reuse Analyses

SG 3 Implement the Product Design

SP 3.1 Implement the Design

SP 3.2 Develop Product Support Documentation

There are a couple of points I’d like to discuss about this area:

1. The 3 specific goals distills a Waterfall process life cycle. After reading carefully the whole process area, I would say that the process suggested would look like this:

1. It selects the solution (SG1)
2. It creates lower lever requirements (SG1 - SP1.2)
3. It creates a broad design (SG2 - SP2.1)
4. And a detail design (SG2 - SP2.1)
5. It implements the design (SG3)

The ways it is written enforces this approach by, for example, specifying the role of the architect who “postulate and develop a model of the product, making judgements about allocation of requirements to product components”

A more Agile friendly maturity model should suggest the following steps in the process development life cycle:

1. It selects a solution
2. It creates a broad design: The architecture. As I said before, there’s a discussion on how much architecture is enough. For sure, in any Agile approach the architecture remains very broad, just with the most important structural components.
3. Design and implement top priority requirements: Detailed design is performed at the same time than implementation of the features.
4. Retrofit project: Designing and implementing a set of requirements increases the knowledge of the product. Requirements and existing design should be refined. This represents the iterative nature of Agile development.

2. The proposed method to the technical solution treats software development as another hard engineering. Let’s not forget that CMMI is used not only in software development process improvement efforts, but also in other harder engineerings. It was the belief a while ago (at the moment of the CMMI writting) that software development could be treated as other engineering fields. There is a very interesting discussion in Alistair Cockburn’s book about treating software development as other engineerings. Anyway, for now let’s just say that software uses a different material than what other engineerings use. Software can be changed more easily. Therefore, it isn’t necessary (or profitable) to have the whole design of the product made up front. The design can be evolved inexpensively (and cheaper if the team uses the practices suggested by Beck). This is completely different than, for example, the case where a bridge needs to be built. In the later, the whole design needs to be specified upfront and changes during the life of the project are very expensive, if not impossible.

Conclusion

Although not said explicitly, the nature of the technical solution process area goes against the nature of the technical aspects in Agile. I believe that trying to fullfill the objectives would lead to too big upfront designs, which in Agile are not recommended. The separation of roles between Architects (the people who take the big decisions up front) and the developers who just need to follow the detailed design provided to them goes in a complete different path than what Agile recommends. Treating Software Engineering as another hard engineer is also not appropriate.
Another thing that caught my attention is that the technical process area doesn’t say anything about good engineering practices. Of course, CMMI is too general to go into these details. However, I wonder if a useful software improvement model shouldn’t provide goals related to this (e.g. one that I would add is having a automated testing strategy, which defines what kind of automated tests are going to be developed during the project and how the product is going to be tested). As a final sentence, I feel this area too far from the Agile technical area.


Other Areas






- Is the Requirements Development Process Area compatible with Agile?
- Is the Configuration Management Process Area compatible with Agile?

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

- 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 Requirements Development Process Area compatible with Agile?

 Introduction

The requirements development process area, a process area at maturity level 2, aims at producing and analyzing customer, product and product components requirements. CMMI states that requirements start as customer requirements (stakeholders expectations are expressed here) and are later refined into product and product components requirements (expressed in a more technical fashion) with the input of the technical members after analysis and design is performed.

Below are the specific goals and practices:

SG 1 Develop Customer Requirements

SP 1.1 Elicit Needs

SP 1.2 Develop the Customer Requirements

SG 2 Develop Product Requirements

SP 2.1 Establish Product and Product Component Requirements

SP 2.2 Allocate Product Component Requirements

SP 2.3 Identify Interface Requirements

SG 3 Analyze and Validate Requirements

SP 3.1 Establish Operational Concepts and Scenarios

SP 3.2 Establish a Definition of Required Functionality

SP 3.3 Analyze Requirements

SP 3.4 Analyze Requirements to Achieve Balance

SP 3.5 Validate Requirements

Is it Compatible?

CMMI states that stakeholders needs, expectations, constraints and  limitations may be difficult to obtain and therefore it suggests an iterative process (very much like Agile). It also states the importance of having a customer surrogate, role that very much resembles that of the Product Owner. However, it also talks about refinement and allocation. I have 2 concerns about those.

Is there really the need to express requirements in a technical fashion? Is it advantageous?

Requirements in a software development project represent the common area of understanding between technical and business people. Refinement of Customer Requirements into Product Requirements implies having 2 sets of requirements and therefore the integrity of both have to be assured (i.e. assure that all customer requirements have been address in the product requirements, which if they are written technically will be inaccessible to business folks). This is not to say that requirements should not be refined. I believe they should, but the end result should be one set of requirements that all members of the project can understand. Some people could say that Customer Requirements may be expressed in a business language too difficult to understand for developers. However, is it possible to build a software system without the developers understanding the business logic of what they are building. I don’t think so. There is another issue that worries me about this refinement. All Agile requirements (User Stories) have some business value associated with them. Although sometimes it can get difficult to slice functionality small enough to enter into an iteration, the advantages of building tangible, visible functionality are many. Although CMMI doesn’t state anything about the business value of any type of requirements, I am afraid that this type of requirements may result in technical requirements without visible value. In any case, stating that all requirements introduce some new business value to the system is really important.

Is there really the need to allocate requirements to technical components?

Who is this useful for? When is it done? Requirements should express what needs to be done. They shouldn’t express how it is supposed to do it. Otherwise, the requirement is biasing the implementation. Traceability is one of the reasons that CMMI states for performing this allocation. However, as I said before I am not sure about the benefits of having this traceability that assures that requirements have been addressed, but not that they have been full filled. Besides, I reckon that this traceability may be too heavy to keep up to date. Instead, I believe that automated tests expressed in the business language provide the certainty that the requirement have been full filled while being always up to date.

Conclusion

Although requirements in Agile should be refined (user stories start as a point of conversation and grow afterwards), the common shared place of understanding is always the product backlog, which is unique set of requirements. Translating customer requirements brings more disadvantages than advantages in my opinion. Same with the allocation of requirements to technical components. Something that really caught my attention is that the CMMI doesn’t say anything about ordering requirements by priority. In Agile, this is a top of the shelf matter, vital to the success of the project.



Other Areas

- Is the Configuration Management Process Area compatible with Agile?

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

- 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 Configuration Management Process Area compatible with Agile?

Introduction

The Configuration Management Process Area, a process area at maturity level 2, aims at establishing and maintaining the integrity of work products. The process area deals with selecting the work products that compose the baselines, controlling changes and maintaining the integrity over these items and providing accurate status on this data.

Below are the specific goals and practices:

SG 1 Establish Baselines

SP 1.1 Identify Configuration Items

SP 1.2 Establish a Configuration Management System

SP 1.3 Create or Release Baselines

SG 2 Track and Control Changes

SP 2.1 Track Change Requests

SP 2.2 Control Configuration Items

SG 3 Establish Integrity

SP 3.1 Establish Configuration Management Records

SP 3.2 Perform Configuration Audits

Is it too Formal?

CMMI states that the first thing is to create a baseline, which is a “a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures.” and then modify this baseline through change requests, which should be approved by all stakeholders. It also states that this process should be audited.

Is this really suggesting that ALL changes should go through a change request system? When the developers are working in the project, they should create a change request ticket to commit their code? When the Product Owner is completing a User Story that was missing some information, s/he should do it via a change request ticket? I believe this formality would take too much time to the activities that add value, hurting the agility of the project. Of course, I believe it is important to track everything under a source control system, to keep the history of all configuration items and to analyze the impact of all changes (specially to requirements). Nonetheless, this should be done in the lighter, more non-obtrusive way. For example, the comments written in the commit to the source control system are (or should be) more than enough information that explains this change. Changes (the history) to the product backlog should be kept automatically, without the Product Owner needing to do anything. Formality is replaced with efficiency and trust. The Configuration System method chosen for an Agile project should be light and efficient. It should keep all the necessary information without the users spending too much time maintaining it. Automation (again in this area) is vital. The easiest way to maintain the integrity of a product is to avoid human intervention in the creation of the product. If the product is created automatically (running a command) there is no room for human mistakes.

Conclusion

When I first read the title of the process area, I thought that this process area was going to be totally compatible. However, after I read it, I began having my doubts. Having to create and maintain a baseline could lead to an overhead that reduces agility. Managing the backlog through change requests is practically impossible. Nonetheless, the need to have all items under a configuration management system is unavoidable. Having all or most of the steps of the configuration management process automated is vital.

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

- 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 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.