Is It Working?

Large and small teams alike have similar criteria for successa working product, model, or simulation. Components must fit together. They must work. They must pass acceptance tests. The longer a team, large or small, goes without delivering an integrated product to a review process, the greater the potential for failure. For large teams , short iterations are used to deliver and integrate components, while milestones are used to deliver and integrate the entire product. Integrated components that work indicate that the team's organizing structure and dynamics are working well. Synchronization problems indicate that organization or process issues need adjustment. Reviews for large teams need to focus on the same topics that those for smaller teams do: the customer's evaluation of the product, a technical evaluation of the product, team performance, and project status. In addition, the success (or failure) of product integration measures how well large project teams are working. Adaptations for larger teams will cover a wider range of issues and problems, but the process is similar to that for smaller projects.

We all know the saying "Don't fix things that aren't broken." For larger teams, we need to give this advice a twist: "Don't always fix things that are broken." While smaller teams are not immune to excessive adaptation, this tendency becomes more prevalent as teams get bigger. Let's say that at the end of a milestone the integration of several modules causes a couple days of extra work. The immediate reaction, particularly by the people who had to clean up the mess, might be to fix the problem by instituting additional coordination meetings. Unfortunately, two things may happen. First, the meetings themselves may take more time than fixing the problem did. Second, there are always different, unanticipated problems that arise. Just as agile teams don't try to anticipate future requirements or design, choosing instead to let them emerge over time, they shouldn't attempt to anticipate every problem and put processes or practices in place to prevent them. It's often cheaper and faster to fix on actual failure than to spend excessive time anticipating failures that may never occur again.