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.

After more than thirty years in information technology, the last fourteen spent focused on testing and quality assurance, Dale Perry has come to believe everyone can benefit from thinking like a tester. In this article, Dale offers comical, yet serious, insight on how a tester views airport bathroom stall designs.