the beginning of every 1-4 week iteration. The big up-front documentation effort that went hand-in-hand with the planning is also drastically reduced, and low-ceremony documentation appropriate for the type and number of the communication nodes involved is embraced instead. Low-ceremony, or low-tech documentation of agile release and iteration plans can consist of several white boards in a war room with color-coded markings, or it can be flip-chart paper taped to the wall with brightly colored notes on each. (For help visualizing this, watch Jim Highsmith's free Webinar on agile project management. http://www.rallydev.com/register_for_webinar_series.jsp#jimPresentation.
Release plans indicating the expected release date and the features to be worked, as well as iteration plans indicating the level of effort in implementing a set of features within the defined timebox, are defined in planning meetings involving the entire team. The team must create, own, and commit to the plan. They cannot be ordered to meet plan specifications written by an individual directing the project. Release plans, iteration plans, and other planning outputs from the envision and speculation phases are then shared with all stakeholders in the most highly visible fashion possible. For co-located teams, this may mean something as simple as posting the plan on the wall. Technical solutions for communication are required for geographically dispersed teams; SharePoint, wikis, and other third-party tools are well-equipped to provide this. Project managers go from writing a large, detailed document defining the plan for the entire project, to facilitating the team in their ongoing iterative planning efforts and sharing that information in the most visible way possible.
Integrated change control also changes dramatically in agile methodologies. In keeping with the idea of minimum process to achieve maximum value, the change control process is streamlined and integrated into the daily routine of agile teams. Product change is managed via the ranked backlog of features. This product backlog is managed by the customer or customer proxy (product manager, subject matter expert), who is responsible for maintaining the list of items to be worked, with the features that provide the most business value to the customer ranked highest.
This backlog contains items beyond functionality requests; technical supporting work and defects are also placed in the backlog and ranked. During release and iteration planning, the highest ranked items move from the backlog into the iterations to be coded, tested, and accepted by the customer. During the iteration, daily 15-minute stand-up meetings are held to apprise each other of status, a key communication element that keeps the team in sync and better able to tackle unforeseen issues.
At the end of each iteration, the working code that was developed is demonstrated, and feedback that may affect future decisions about the items in the backlog and ranking is gathered from stakeholders. Process changes are also made at the end of the iterations, allowing the team to make course corrections not only in the product, but also in the way they work. The team--customer, developer, tester, analyst, technical writer, and project manager--becomes the equivalent of a change control board. They streamline the process so that decisions are made quickly, collaboratively, and with little to no ceremony.
Click Here to Read Relating PMBOK Practices to Agile Practices Part 2 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 3 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 4 of 4