Since the early days of agile, we've known that face-to-face communication is optimal. In fact, one of the twelve principles in the Agile Manifesto is, “Business people and developers must work together daily throughout the project.” So, what are the real differences between collocated and distributed teams with the advent of “closeness” technologies-Web-based meetings, shared project whiteboards, Skype, Wikis, video conferencing, and more? Through a series of stories about teams he’s worked closely with over the past few years, Michael Feathers explores the issues surrounding team collocation. Whether you are lucky enough to have your entire agile team together or are required to work apart most or all of the time, you'll discover new ways to encourage collaboration and build personal relationships. In the end, you'll arrive at your personal understanding of what "being there" means.

Agile, waterfall, iterative, staged, gated, phased-none of it really matters if all you create are a few early "wins", mediocre solutions, and quick fixes. Many organizations twist the time pressure screws so tightly that creative thinking can only be done after work or surreptitiously during the five-minute coffee break or the fifteen-minute lunch at your desk. We often are told that “good enough” software is what the company needs. Although “good enough” is acceptable when the systems we create neither differentiate us from our competitors nor are critical to our mission, why do we waste precious resources creating those kinds of systems? Tim Lister knows that there is hope because many organizations do create superior systems-systems that set them above their competitors and wow their customers. What are these organizations doing to yield innovative, superior results from their software development?

Software quality often gets lots of lip service and little else-until its absence triggers a disaster and stuff hits the wall. Don Beckett shares work he did to determine when the software for a satellite destined to orbit the earth was sufficiently stable to risk being launched. Failure would have cost hundreds of millions of dollars. Don shows how he modeled this problem to answer the “launch/don't launch” question. Beginning with an analysis of the factors that determine acceptable quality and the issues that confront defect collection, Don overviews how defect discovery follows a Rayleigh curve distribution that anyone can use for predicting defects remaining in a system. He shares a model of how staffing and scheduling trade-offs will almost certainly impact defect creation rates.

By its very nature, the endgame of software projects is a hostile environment. Typical dynamics include tremendous release pressure, continual bug and requirement discovery, exhausted development teams, frenzied project managers, and “crunch mode” for testers. However, hope and relief are available. By using metrics derived from defect discovery and repair patterns, you can learn how to guide projects toward a successful release with less stress and more certainty. Bob Galen shares patterns that you can mine from your defect metrics to focus your entire team on a few key performance indicators. Examine defect patterns, maturation rates, and other organizationally unique patterns that you can leverage as project milestones. Learn about the Pareto Principle and its implications on defect actions and workflow. Next time, you’ll be better prepared for your project endgame and increase the likelihood of an on-time delivery.