Characteristics of Agile Life Cycles

This post is part of my notes for the Agile Practice Guide.   I have taken notes on the 4th Edition of the guide to the Project Management Body of Knowledge (or PMBOK Guide for short) in preparation for my CAPM certification in 2012; then for the 5th Edition which came out in 2012, and most recently for the 6th Edition which came out in September 2017.   I did it not just for myself, for the study group I helped run, first as an assistant to the Director of Certification when I was at the Orange County, CA chapter, and then as the Director of Certification at PMI Chicagoland when I moved to Chicago in 2013.

But with the publication of the 6th Edition of the PMBOK Guide, my notes would not be complete without my notes for the companion publication to the PMBOK Guide, namely, the Agile Practice Guide put out by the Agile Alliance in conjunction with PMI.

This third chapter of the Agile Practice Guide compares and contrasts agile with the three other life cycles for projects:   predictive (traditional or waterfall), iterative, and incremental.   I never clearly understood before the difference between iterative and incremental, or how knowing how those two life cycles work helps you understand agile, which combines features of both.   This chapter clears all of that up very helpfully, and I hope you find that it does the same.

After comparing and contrasting the four life cycles in the first part of the chapter in a more general way, the Guide goes into details about each of the four life cycles in the next part of the chapter.   I already did three posts on the other life cycles, so this post will cover agile.

Agile incorporates elements of iterative and incremental and iterative life cycles in that a) it goes through work in iterations (cycles), and b) it delivers incrementally to the customer, gaining feedback afterwards which may change the requirements.   It is used to adapt to high degrees of change and deliver project value more often.

Incremental delivery can happen in one of two possible ways so that the project aligns with customer needs.

Iteration-Based Agile

In each iteration, the timebox (length of time of each iteration) is the same size.  Each timebox results in working tested features.   So with each iteration you will have the same steps:

  • Requirements
  • Analysis
  • Design
  • Build
  • Test

For each timebox, the team works on the most important feature, and collaborates as a team to finish it.  Then the team works on the next most important feature and finishes it (and so on).

Flow-Based Agile

In each iteration, you have the same steps as above, namely:

  • Requirements
  • Analysis
  • Design
  • Build
  • Test

However, the timebox (again, the length of the iteration) is not the same each time, but is based on the number of features in the Work In Progress (WIP) limit.   The time it takes to complete a specific feature is not the same for each feature, and that is why the length of the timebox may differ.

The team defines its workflow with columns on a task board and manages the work in progress or WIP for each column.   Because the iteration is not a fixed length, it is important that the team and stakeholders determine the most appropriate schedule for planning, product reviews, and retrospectives.

As we head towards 2020, more and more projects are becoming hybrid projects, that is, projects that use a combination of predictive, iterative, incremental, and/or agile approaches in a hybrid approach.

The next post will cover characteristics of hybrid life cycles.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: