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:

It selects the solution (SG1)
It creates lower lever requirements (SG1 - SP1.2)
It creates a broad design (SG2 - SP2.1)
And a detail design (SG2 - SP2.1)
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:

It selects a solution
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.
Design and implement top priority requirements: Detailed design is performed at the same time than implementation of the features.
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?