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.

Advertisements

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.

Demonstrations/Reviews in an Agile Environment


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 four items.s on the list in the last few posts.   The previous item I covered was Daily Standups.  The next item I will discuss in this post is demonstrations or reviews.

Once a team completes a feature, the team needs to demonstrate the working product.   In a traditional project management environment, this is called “verifying the scope” internally before the scope is validated by the customer.

The customer will then give feedback and the team will implement any changes suggested.

As a general rule, the team should demonstrate a working product at least once every two weeks.  A team that does not demonstrate a product with that frequency needs coaching to enable frequent delivery.

The next post will cover the next item, planning.

 

Stand-Ups in an Agile Environment


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 three items on the list in the last few posts.   The previous item was about the backlog refinement process.   Now I’ll start on the fourth item, which is daily standups.

The purpose of standup meetings is to:

  • make commitments to others on the team
  • uncover problems
  • ensure the work flows smoothly through the team.

The standup should take no longer than 15 minutes, according to the Guide.

The questions that everybody on the team should answer in a round-robin fashion are the following:

  • What did I complete since the last standup?
  • What am I planning to complete between now and the next standup?
  • What are my impediments (or risk or problems).

These questions make people accountable to each other for work they committed to doing in the previous day’s standup.   If the work was not completed, the focus in not on the blame, but the barrier which caused the work not to be completed.

It may be helpful to understand what a standup is by listing some things that it is not.

  • It is not a status meeting–that would only cover the first question listed above.  It is asking the second question above (“what am I planning to complete?”), which covers the purpose of “make commitments to others on the team.”   It is asking the third questions above (“what are my impediments?”), which covers the purpose of “uncover problems.”
  • It is not a problem-solving meeting.   The problems are uncovered during the standup, but individual problem-solving sessions can occur after the standup.

The standup, in short, is a way of fostering intense collaboration among members of the team, and that is one of the reasons why it is one of the eight most common agile practices introduced in Chapter 5 of the Agile Practice Guide.

The next post will cover the fifth item, demonstrations or reviews.

 

Backlog Refinement in an Agile Environment


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 two items on the list, retrospectives, in the last few posts.   The previous item was the preparation of the backlog, done by the product owner.   Now I’ll start on the third item, which is backlog refinement.    This is where the product owner takes the backlog he or she created and takes it to the team for … well, refinement.

What does “refinement” mean in this case?

  1. The team has to understand what the stories mean, so that if the description by the product owner was not sufficient, the team can ask the product owner questions to make sure the meaning is clear.   If the team finds that there are potential challenges or problems in the stories, then the product owner can request the team to spike the feature in order to further explore the risks involved before committing to it.
  2. The team has to understand how large the stories are in relationship to each other.  This is key to planning in an agile environment (this is an item to be discussed in a later post).

What should the format of the refinement meeting be?   There are several ways of going about it:

  • Just-in-time refinement (for flow-based agile).   The team takes the next card off the “to-do” column and discusses it.
  • Iteration-based refinement, done for one hour midway through an iteration.
  • Multiple refinement discussions for teams that are new to the product area.

In any case, the Guide recommends that the refinement meeting not be more than one hour per week.   If the team is spending more time than this, it could be that the team may be lacking the critical skills needed to evaluate and refine the work.

One interesting possibility that the Agile Practice Guide mentions is the combination of the backlog preparation and backlog refinement.   This is where the team participates in the preparation of the backlog, and not just its refinement.

Here again, the Guide suggests several ways of going about this combined process:

  • The product owner presents the overall story concept to the team, and have the team discuss it and refine it, splitting it into several stories if needed.
  • The team splits into three groups taking the roles of a developer, tester, and business analyst/product owner to collaborate in writing the story.   With input from all three groups, the story should end up being understood by all of the team.
  • The team works on producing stories on a daily basis that are small enough so that they can be completed in a single day.   This will ensure that the team can complete a steady flow of completed work.

Whether the product owner does the backlog on his or her own, and THEN presents it to the team for refinement, or works with the team to create and refine the backlog, the end point is the same.   The team should understand the stories well enough to estimate their size, prioritize them, and then get to work!

 

Using Retrospectives for Personal Time Management


After completing two posts on the use of retrospective meetings in an agile environment, I had to relate some thoughts I’ve been having about why the planning system I’ve been using has worked so well for me.

I started using the Full-Focus Planner system by Michael Hyatt back in 2018, and renewed my subscription to receive more planners in 2019.   I’ve been thinking about why I made that decision.   Of course I chose it because it works, but why does it work so well?

Well, that came to me while I was doing the previous posts:   most planners have pages for each day of the week, but the Full-Focus Planner has a few extra pages which it calls the Week in Review.   The things you would expect to see in an agile retrospective–what worked and what didn’t work–are here as well.    Plus a section on action items you can take in order to improve things.

I think this weekly review is part of the reason why it has been such a successful tool for me.   If you see that something is not done that needs to be done, you can schedule it again with a higher priority.   If it still doesn’t get done, then you know that there is some procrastination issue going on.   If that’s the case, you can do things like:

  • get help from someone else
  • break a large task into smaller ones
  • use the Pomodoro method of doing only 30-minutes of work at a time on the task, where you actively work for 25 minutes and then give yourself a reward of 5 minutes spent on some pleasant activity.

But it is also a reflection on what has been done and particularly what has been done well, so you can use it give yourself a confidence boost.   But, like in agile, it is the regularity of the review that is important.   And, the attitude is also important:  just like in an agile retrospective, it is not the time to look at yourself and heap blame upon yourself for not accomplishing this or that task.   The focus should be:  what’s done is done.  Now what?

One way to get your personal retrospectives like the ones in agile is to get yourself an actual kanban whiteboard to plan and track tasks, or to use one of the many kanban apps for personal use that are coming online.   Doing something visually in conjunction with your hands ignites a lot more mental pathways in your brain than just scanning a list visually.

Now let’s move on to the next activity that is considered key in agile projects:  that of creating and then prioritizing a backlog list, the equivalent of a work breakdown structure in traditional project management.  That will be the subject of the next post.