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.

The Agile Revolution

Guiding Principles: Customers and Products

Guiding Principles: Leadership-Collaboration Management

An Agile Project Management Model

The Envision Phase

The Speculate Phase

The Explore Phase

The Adapt and Close Phases

Building Large Adaptive Teams

Reliable Innovation



Agile Project Management. Creating Innovative Products
Agile Project Management: Creating Innovative Products (2nd Edition)
ISBN: 0321658396
EAN: 2147483647
Year: 2003
Pages: 96
Authors: Jim Highsmith

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net