4squareviews

I’m going through the Agile Practice Guide on a systematic basis to review all of its contents.   Chapter 5 covers the implementation of a project in an agile environment.

Section 5.2 of this chapter covers the eight most common agile project practices, which are:

5.2.1 Retrospectives

5.2.2 Backlog preparation

5.2.3 Backlog refinement

5.2.4 Daily Standups

5.2.5 Demonstrations/Reviews

5.2.6 Planning for Iteration-Based Agile

5.2.7 Execution Practices that Help Teams Deliver Value

5.2.8 Iterations and Increments Help Deliver Working Product

The first seven practices were covered in earlier posts.   The eighth practice is using iterations and increments to help deliver the working product.

First of all, to understand the context for this practice, you should refer to Chapter 3 which refers to the four types of project life cycles:  predictive, iterative, incremental, and agile.

1. Predictive is simply the traditional project management life cycle.   The requirements are fixed at the beginning, the activities are ideally performed once for the entire project, and the delivery of the final product being done once at the very end.
2. Iterative is a project life cycle where the requirements are dynamic (i.e., can change during the course of the project), the activities are repeated to allow feedback on partially completed or unfinished work so that the work can be improved and modified until a correct solution is found.    Like the predictive model, the delivery of the final product is done at the very end.
3. Incremental is a project life cycle where the requirements are dynamic, and the work is broken down into smaller deliverables.   The activities that are done are repeated for each deliverable.   The big difference here is that the delivery of the project is done incrementally in deliverables that the customer may be able to use immediately.
4. Agile is a project life cycle which leverages both the aspects of iterative and incremental project life cycles.   On the one hand, an agile team iterates over the product to create finished deliverables.    Feedback is obtained early on from the customer, which gives the customer a voice in what the final product will look, feel and perform.

This is why the practice listed here is how to use both iterations and increments to help design a better product.

For iterations, it is best to refer to the first practice on the use of retrospective meetings which serve to punctuate the flow of work in order to create a cadence for delivery and a time for reflection as a group to give feedback on how the process is going.

For increments, it is best to have a process in place where

a) the testing is done by the group to assure that the deliverable achieves the user story that it was based on.   This is the equivalent of scope verification in a traditional project management framework

b) the customer receives the deliverable and is given a demonstration.  The customer gives feedback on whether, from the customer’s standpoint, the deliverable achieves the user story as promised.   This step in the process can be problematic if the customer does not know beforehand what the user story is, or has an understanding of it that differs from that of the agile team.    This is why the user story has to be written in an objective manner, so that subjective interpretations of what it means can be eliminated as much as possible.    This is the equivalent of scope validation in a traditional project management perspective.

c) The team then takes the feedback from the customer on how the product looks, feels and performs, and then in the next retrospective they will either continue on to the next deliverable, or if there is negative feedback, they will discuss how to adapt the product in order to have it conform to the customer’s expectations.

So the feedback created at the end of increments  are used as the raw data which drives the analysis done during the retrospectives.   This is why agile is considered a project life cycle in which iterations and increments work together hand in glove.

This concludes this series of posts on how to execute an agile project.

The next section, section 5.3, discusses troubleshooting agile project challenges.   In a manner typical for PMI, these 21 challenges or pain points are listed in a laundry-list fashion, with no clear thematic group (at least that I can see).   So I am going to analyze these 21 challenges and see which can be grouped together based on the nature of the troubleshooting possibility (the creation of an agile charter, the development of a product backlog, the role of the servant leader or product owner, etc.).   The first post will be those agile challenges that can be remedied by creating an agile project charter.

Filed under: Uncategorized |