Is the Product Integration Process Area compatible with Agile?

Introduction

The Product Integration Process Area, a process area at maturity level 3, aims at “assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.”

Below are the specific goals and practices:

SG 1 Prepare for Product Integration

SP 1.1 Determine Integration Sequence

SP 1.2 Establish the Product Integration Environment

SP 1.3 Establish Product Integration Procedures and Criteria

SG 2 Ensure Interface Compatibility

SP 2.1 Review Interface Descriptions for Completeness

SP 2.2 Manage Interfaces

SG 3 Assemble Product Components and Deliver the Product

SP 3.1 Assemble Product Components

SP 3.3 Evaluate Assembled Product Components

SP 3.4 Package and Deliver the Product or Product Component

What should be the integration procedure suggested by Agile?

If the project is small and the contractual possibilities allow it, the recommended approach should be without any doubt to do Continuous Integration with all the practices suggested by Fowler in his great article (everyone committing to the same mainline, every day). What if the project is too big or a 3rd party team develops certain components of the system? Probably the different components are developed separately and then integrated. The question is how and how often.
One option is to study carefully the integration points before starting developing, then develop the different components (based on the documents created during the BUFD) and then integrating everything in the end. This approach has been proved too risky. No matter how well agreed and documented the integration points are, if there is a problem, it happens when the project has consumed most of its budget and changes are too expensive to be applied. The opposite option would be that all teams (belonging to all components) try to use the same mainline. Sometimes, this can be troublesome as it can happen that the different teams create problems between each other. So some separation, in these types of projects, could be valuable. However, I believe that the separation needs to be made following the Continuous Integration values. So if in a small project, the rule is that every developer integrates and commit every day to the mainline, the development of a big system could be done slicing the products in a way that many integration points are planned. Perhaps once a week or once a month, depending on the project. Of course this creates overhead, specially I can imagine if a lot of mocks and doubles needs to be constructed. However, the risk is also sliced and minimized throughout the project.

Does CMMI recommends one approach?

It is not clear to me, to be honest. In the description of the process area, it states that “Product integration can be conducted incrementally, using an iterative process of assembling product components, evaluating them, and then assembling more product components.”. However, again the sequence of goals would seem to suggest that a big analysis should be conducted at the beginning, then the interfaces should be managed and at the end the final product should be assembled, using the sub-components. This looks to me as goals that are more related with building a car than building software.

Conclusion

The Agile approach towards integration should be to it continually. How continually? As continually as it possibly can be performed. Remember that what needs to guide the decisions are the values and the principles. What is the rationale for doing Continuous Integration? How can it be applied to this particular project? These are the types of questions that should guide decisions.