Toby Sarver
Many commonalities between agile methodologies arise from a "pay as you go" approach. That is, you make some investment in effort that you hope will have immediate payback (e.g., the system has more functionality). This contrasts with heavy-weight processes where the payback may not come until the end of the project (e.g., at integration). Even when you're re-factoring for no apparent improvement in functionality, you're really enabling the system to accept the next story.
Agile processes are deliberate strategies to do as much as possible with what you know and to avoid acting on partial knowledge. There is a fascinating article in CACM describing a software project as a knowledge discovery process, where the code is actually the knowledge repository. The agile approach is a methodology for acting on knowledge (e.g., designing, coding, building GUI, etc.) and acquiring knowledge (e.g., the Planning Game, user stories, etc.).
Since you're trying to only work with what you know (which is hard to distinguish from you think you know), your plans generally have short horizons.
Many organizations that adopt an agile process usually have a short meeting everyday. The primary reason is to decide what everyone will do today. In addition to respecting the "principle of short horizons", it disseminates information about:
Disseminating knowledge among team members is critical to an agile project. In addition to the daily meeting, pair programming is a really good way to share knowledge about the design details, best practices, patterns, and other useful information. At a higher level, metrics gathering lets the whole team (including the Customer) know how the project is doing.
My position is that not only are there specific ways that different Agile Processes are similar, but that there are underlying reasons or approaches that they share that explain the similarities. I'm interested in looking at the similarities in order to learn the underlying mind-set that explains them.
While at the University of Florida in 1986-88 I worked as a research assistant in the Software Engineering Research Center comparing various object-oriented methodologies. In 1988-90 I worked in Andersen Consulting integrating object-oriented methodologies into their proprietary methodology. In 1997, I applied the SCRUM process at Fidelity Investments. I helped Fidelity develop and apply their own rapid development methodology in 1998-99. I learned about XP and had the opportunity to work with Ken Auer and his team at Role Model Software in 2001.
Toby Sarver
Principle Technologist
New Object
Solutions
newobjects@nc.rr.com
3213 Watkins Glen Ct
Raleigh, NC
27613
919-848-6323