Article: What is Agility, and Why Should You Care?

Alright, that's all very plausible: TDD, shorter iterations, more customer involvement, quickly adapting plans to feedback, etc. But there are two elephants in the room that need to be talked about: Contracts and coordination between multiple projects/parties. Both have a tendency to contradict agile principles because they are simpler to do when things are cast in stone at a particular time. Re-negotiating contracts, interfaces and schedules takes time too. I would be very interested to hear about agile contracts and agile multi-party coordination.

Multi-party coordination is fairly simple: just follow the same basic principles and discipline including self-managing teams, amplifying learning and eliminating waste. In practice this means that as much as possible, you want to:
- avoid long approval processes that require chains of management in separate organizations
- put people in the same room together even if it means flying people around the world (that's inexpensive compared to the cost of mistakes due to mis-communication)
- use the "Scrum-of-Scrums" status reporting method where representatives of each team involved regularly share status

These techniques are not easy. They often take considerable management support to put into place. Even more important though is that they require TRUST among the parties involved. This is the underlying foundation for agile methods. It is relatively easy to establish a workable amount of trust in a small team in a single organization. It is much harder to do this in a multi-team, multi-organization environment. Nevertheless, in order to use an agile method, one must be able to establish trust.

If you are unable to establish "agile contracts" with your clients/suppliers, it is likely because of a lack of trust. I'm not an expert on agile contracting (I've focused more on single-organization agile implementations), but I do know that Mary Poppendieck has a lot to say on this topic (www.poppendieck.com) and that Toyota and their relationship with their suppliers is often held up as a good example of trust-based inter-organizational relationships.

Our company is embarking to be certified for CMMi Level5. During initial briefings, we're seeing a lot of additional documentation activities for tracking, metrics, etc. I'm just curious how would an agile process and CMM fit together?

CMM and agile can fit, but most approaches to CMM are very document heavy and _not_ compatible. CMM is usually used as a prescription to improve the maturity of a software development/IT organization. However, CMM is meant to be a descriptive model. The additional activities that you are seeing are only useful if they don't become barriers to your primary goal: organizational success. In software development/IT, your contribution to organizational success is primarily dependent on being able to deliver working systems in a timely manner that actually satisfy customer/stakeholder needs... as they pertain to organizatonal success. If CMM is adding a lot of documentation, it is likely going to end up hindering your ability to deliver working systems in a timely manner. Check out my article The Art of Obstacle Removal and my whitepaper (pdf) about the relationship between lean and agile methods.