Using Iterations and Increments


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.

Execution Practices on an Agile Project


 

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 six practices were covered in earlier posts.   The seventh practice is actually a bundle of execution practices that are designed to help quality on the project.

  1. Continuous integration–as each module is designed, the entire product created so far must be retested to make sure that it still works as intended.
  2. Test at all levels
    • Unit testing should be done for the building blocks, and then
    • System-level testing  should be done to make sure that the building blocks are communicating data properly.
    • Smoke testing, also known as “Build Verification Testing”, is a type of software testing that is comprised of a set of tests that aim at ensuring that the most important functions work.  The result of this testing is used to decide if a build is stable enough to proceed with further testing.
    • After smoke testing, regression testing is done.   Regression testing is when you are testing around specific areas of an application where defects have been fixed to ensure that no other issues have been introduced.
    • Agile teams have a strong preference for automated tests that ensure uniformity of testing through the design-test-deliver cycle (see paragraph 3 below regarding ATDD).
  3. Acceptance Test-Driven Development (ATDD)–the entire team gets together ad discusses the acceptance criteria for a work product.   Based on these agreed-upon criteria, the team creates automated tests that will allow the work product to be tested to see if it meets the acceptance criteria.
  4. Test-Driven (TDD) and Behavior-Driven Development (BDD)–the advantage of writing the automated tests before creating the product is that it actually helps people doing the design and it helps mistake-proof the product.
  5. Spikes (timeboxed research or experiments)–spikes are concentrated periods of focus not on creating the product itself, but on doing work which helps facilitate that creation.   They are used when the team needs to learn more about some critical technical or functional elements.   Examples of such research are:
    • estimation
    • acceptance criteria definition
    • understanding work flow

The last practice is the eighth and final one on the list at the top of the post, namely, implementing iterations and increments in order to help deliver work product.   That will be the subject of the next post.

Planning for Iteration-Based Agile


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

I covered the first five items in previous posts.   The sixth item is what I’m covering today.    There are two ways of managing the work flow on an agile project:

  • Flow-based:  an iteration is considered complete when the team reaches some sort of milestone, like when it completes a major deliverable, ships something or even completes a release.   It is based on the completion of a definable chunk of work.
  • Iteration-based:  an iteration is done on a regular basis, with a two-week iteration being the most popular.

The common agile practices related to planning for iteration-based agile (the second option above) are what is being covered today.

First of all, the team must establish the length of the iteration, with two weeks and four weeks being the most popular options.   Note that it is possible for a new team to meet once a week at the beginning when the team is getting used to working together, and then lengthening the iteration to two weeks once there is a rapport established between team members.

Second, the group needs to decide what story size the team has the capacity to handle within a given iteration.

Third, the product owner has to take into account when people are unavailable, as they will not be working at full capacity or perhaps even at all (for example, when they are in vacation).   When teams have a reduced capacity, the team needs to plan for work that meets that capacity.

Fourth, it is best for the product owner to make the stories smaller in the beginning so that the teams see progress in the form of a finished product, and therefore gain confidence to be able to take on more work during an iteration.

The big takeaway from agile planning vs. traditional project management planning, is that in agile, you do not plan just one in a single chunk, but a little at a time.   Once the work is delivered, the retrospectives described in an earlier post keep the team on track, so that they can plan a little more of the work for the next cycle.

So this deals with managing the scope, a measure of the completeness of the work.   The correctness of the work is also vital, and that takes you into the domain of quality.

The next post will cover the execution practices that help teams deliver value.