Staying Agile: Is It Possible?
The aforementioned Agile values, however, are not applicable in every environment. Just consider an international corporation with its software R&D spread over three continents, with R&D serving other departments of the organization located all around the world. Is it possible to locate the “Customer” together with R&D team? What about processes, multilingual manuals, corporate and R&D budgeting, and delivery – plus resource planning?

In big companies, the Software Development activity (and many others) is increasingly being outsourced to offshore premises and providers, creating a growing need in Requirements specification and project progress control. In all these situations, code is not the only artifact to be produced.

These facts are, among others, the foundations of the CMM evolution into CMMI [CMM]. The aim of CMM was to certify the development ability of a software R&D team, while CMMI certifies much wider business processes inside an organization including software development. Another very interesting reason for moving CMM into CMMI is the need for integrating corporate processes and software development.

In light of this, CMMI and Agile methods seem to be incompatible, due to the much broader coverage of the former compared to the latter.

Paulk [Pau01] tackled the issue of integrating XP and SCRUM with CMM and found that there are some areas in CMM that fall outside the coverage of the considered Agile methods. Such not-covered areas affect process and project control and the monitoring and control of suppliers.

Another interesting perspective is related to Customer involvement. For complex systems this often cannot be solved by having the Customer sit with the R&D team because formal Requirements gathering and refinement is performed by dozens or even hundreds of people, geographically dispersed as often as not. Davies in [Dav05] states that Requirements definition activities nearly always produce documents that are directed from writer to reader, such as from the Customer to R&D, and frozen – i.e., not supporting change – and this is in direct conflict with iterative and change-driven Agile methods.

Another interesting fact is noticed in [Kan02]: “In spite of what many people think, it is not true that Agile methods are without artifacts, although they are certainly less documentation-focused than traditional techniques. Still, this is an issue for organizations for whom the CMMI is the basis for rating their organization.”

So Corporate Governance, Project Management, and Requirements Management disciplines in a big and/or distributed company can actually suffer from the introduction of Agile methods in R&D. Is a reasonable compromise even possible?

The answer can be found in one of the principles of the Agile Manifesto itself:

“Give them the environment and support they need, and trust them to get the job done.”

This could be interpreted as “give Developers a toolset that is fully integrated in the wider processes of the Company and let them collaborate remotely as if they were on the same site as their Customer, and let their work be seamlessly audited and controlled”.

In practice this means that while Developers are coding in an Agile world using Agile tools, other people in the Company must be able to define and refine Requirements, submit changes, and track project status using their favorite methods and tools.

Is that realistic? Are tool vendors providing anything that addresses this need?