There are two distinct roles in many software projects that are involved with testing: developers and testers. Should they take the same approach to testing, or are there some principles that apply to only one of the roles? What should they do to coordinate their work? Danny Faught went through an exercise to compare and contrast and found that the questions he couldn't answer were as interesting as the questions he could answers.

If you hear that someone doesn't have "both oars in the water," you know he's out of control, he doesn't "get it," or he's going in circles. Why? To move forward in a rowboat, you need both oars in the water to steer and to gain speed. In this week's column, Mary Gorman explains how this concept applies to modeling requirements.

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.