Early implementations of Agile focused on brand new or newer product-lines. More recently, Agile is gaining acceptance in the legacy product space where the project teams are moving away from their company's traditional (aka, waterfall) methodology and moving toward an Agile approach. In these cases, the project team that begins to use Agile methods are typically inheriting an existing infrastructure that was constructed for a phased (aka, waterfall) approach.

It is possible to apply techniques borrowed from social network analysis) to software development teams. Once revealed, social networks can be actively or passively stimulated for the benefit of team formation and cohesion. Agile principles incorporate social network stimulation on an almost subliminal level; this is one of the reasons why agile principles work.

The first part of this article introduced the concept that developing a complex software system was like going on a journey. I contrasted how we plan our journeys through the use of route planning systems against that of an agile journey which is more like using a GPS in our car. I also introduced the idea that we only know when we have reached our journeys end (being completely done) when we have demonstrated that we have fully satisfied the expectations of the customer, our criteria for a successful outcome and that we can use this thinking throughout our project so that each iteration delivers software which can achieve a successful customer outcome.

Agile Coaches have a big job.

"Support the team but not too much and not too little."

"Be available but don't be overbearing."

"Offer ideas but don't get too involved."

"Coach, don't manage."

All this advice can be confusing, even contradictory. No wonder Agile Coaches fall into less-than-desirable behaviors as they try out new things to help teams. The problem is that these behaviors can subtly undermine a team's ability to organize, improve and, eventually, reach high-performance. That's why they are called failure modes.