Mixing Agile Approaches

In the third chapter of the Agile Practice Guide, the four life cycle approaches for projects are compared and contrasted.

The first part of the chapter compared and contrasted the approaches, and the next part of the chapter went into more details for each approach.

Then the next section, which I just finished posting on, talks about hybrid life cycles which take elements of the different life cycle approaches and combines then.

This next topic in this section about hybrid life cycles goes into details about mixing or blending different agile approaches.

The example given on p. 31 is one of the most common blends in widespread use, involving each of the following three approaches:

  1. Scrum–provides guidance on the use of a product backlog, a product owner, scrum master, and a cross-functional team–includes sprint planning, daily scrum, sprint review, and sprint retrospective sessions.
  2. Kanban–a kanban board helps the team to further improve its effectiveness by visualizing the flow of work, making impediments easily visible, and allowing flow to be managed impediments easily visible.
  3. XP–use of story cards, continuous integration, refactoring, automated testing, and test-driven development.

The blend of practices from these various produces a synergistic result of higher performance than each individual component in isolation.

The next post will discuss some of the project factors which will help you determine how to tailor the various options among hybrid approaches for your project.

Characteristics of Hybrid Life Cycles

This is a series of posts on the characteristics of various life cycles, based on the material in chapter 3 of the Agile Practice Guide.   The chapter compares and contrasts the four types of project life cycles:

  • Predictive (traditional or waterfall)
  • Iterative
  • Incremental
  • Agile

The first part of the chapter did a comparison between the four types.   The next part, which I’ve covered in the last four posts, goes into more detail of the characteristics of each type.   This posts goes into the section which talks about characteristics of hybrid life cycles, which is a combination of predictive, iterative, incremental, and/or agile life cycles.

There are several ways to create a hybrid life cycle.

1.Agile Development Followed by a Predictive Model

The early processes utilize an agile development life cycle, followed by a predictive roll-out phase.    This approach is used when there is uncertainty, complexity, and risk in the development portion of the project, which makes the agile approach beneficial for that portion of the project.   The roll-out phase, if it defined and repeatable, can be undertaken in a predictive team.

EXAMPLE:   Development of a new high-tech product through agile methodology followed by roll-out and training to thousands of users using predictive project management

2.  Combined Agile and Predictive Approaches

This is actually a common scenario.   Some approaches are taken from agile, such as:

  • short iterations
  • daily standups
  • retrospectives

However, other aspects of the project may still follow predictive approaches such as:

  • upfront estimation
  • work assignment
  • progress tracking

EXAMPLE:   When a team is incrementally transitioning to agile.

A gradual transition to agile involves adding more iterative techniques to improve learning and alignment among teams and stakeholders.   Later, more incremental techniques can be added to accelerate value and return on investment sponsors.

Usually an organization tries to transition to agile on less risky projects with a low-to-medium degree of uncertainty.   Once this transition is successful, larger, more complex projects can be tried using agile techniques.

3.  Predominantly Predictive Approach with Some Agile Components

In this case, a portion of the project with uncertainty, complexity, or opportunity for scope creep is being tackled in an agile way, with the remainder of the project being managed using predictive approaches.

EXAMPLE:  An engineering firm building a facility with a new component.   The agile component of the project deals with the new component in order to uncover issues early on while there is time to incrementally improve the process through experimentation and adaptation before it is incorporated into the rest of the facility which has been previously built before (and can therefore be dealt with using predictive approaches).

4. Largely Agile Approach with a Predictive Component

This approach might be used when a particular element is non-negotiable or not executable using an agile approach.

EXAMPLE:  Integrating an external component developed by a different vendor that cannot or will not partner in a collaborative or incremental way.  After the component is delivered, a single integration is required.

To conclude this discussion, note that project teams may design a hybrid life cycle based on project risks.   The higher the risk, the better that portion of the project is to be handled through agile methods.  The goal of project management is to produce business value in the best possible way given the current environment.

Is feedback needed from customers as the team produces value?   Then, try incremental life cycle approaches.

Is it necessary to manage risk as ideas are explored?   Then, try iterative approaches.

But, if the organization cannot deliver intermediate value (such as with construction projects) agile approaches may not be useful.   Only use agile if you need frequent customer-based delivery.  The feedback from the customer will be used to plan and replan the next chunk of work.

This post has talked about mixing life cycle approaches.   The next post will talk specifically about mixing agile approaches, and what some of the common blends are of agile frameworks used on projects.


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.



Characteristics of Incremental Life Cycles

This is a series of four posts I am doing based on the material in chapter 3 of the Agile Practice Guide.   The first part of this chapter compares and contrasts the four project life cycles:  predictive, iterative, incremental, and agile.   The following posts go more in depth in terms of the details of each life cycle.   I have covered predictive and iterative life cycles in my previous posts; in this post I go through the material on p. 22-23 of the Agile Practice Guide.

As opposed to the iterative life cycle , with its focus on quality and getting to a single correct solution, the incremental life cycle has a focus on speed of delivery.   Many initiatives cannot wait for everything to be completed; the customers are willing to receive a subset of the overall solution and have it supplemented in future releases of the product.   The frequent delivery of smaller deliverables is called an incremental life cycle.

Incremental life cycles optimize work for delivering value to sponsors or customers more often than a single, final product.   The initial deliverables are planned before beginning the work, and that first delivery is worked on as soon as possible.

The team may deviate from the original vision of the product based on customer feedback received after the initial deliverable, perhaps a single feature of the proposed finished piece of work.

The key is to deliver a minimum viable product (MVP) to a subset of customers.   The customers can use the product and provide customer feedback, which helps the team to learn what they need to provide for subsequent delivery of the final finished feature of the product.

So as opposed to a predictive life cycle, which delivers business value only at the END of a project, an incremental life cycle delivers business value more often.

It is important to understand the iterative AND incremental approaches, because the next life cycle to be covered in this series of four posts, the next one on agile, combines elements of BOTH.

Characteristics of Iterative Life Cycles

This is the second of four posts covering the characteristics of the various life cycles of projects, including predictive, iterative, incremental, and agile.   It is based on the material on p. 21 of chapter 3 of the Agile Practice Guide.

First of all, remember that iterative life cycles allow feedback on partially completed work to improve and modify that work repeatedly until a correct solution is found.

These modifications are done through successive prototypes or proofs of concept.  Each new prototype is reviewed by the team, which generates insights for the next iteration.  In addition, it is shown to the stakeholders, yielding new feedback which also helps guide the next iteration.   The next iteration may be planned by timeboxing, that is, by setting regular intervals such as 2 or 4 weeks.   The iterations help identify and reduce uncertainty in the project.

Projects benefit from iterative life cycles when:

  • complexity is high
  • when the project incurs frequent changes
  • or when the scope is subject to differing stakeholders’ views of the desired final product.

Iterative life cycles may take longer because they are optimized for learning and achieving a single correct solution as opposed to speed of delivery.

Here are the steps of an iterative project life cycle (see Figure 3-3)

  1. Analyze
  2. Design
  3. Create Prototype
  4. Repeat steps 1 and 2 as necessary
  5. Build
  6. Test
  7. Deliver

Item 4 above covers the “iterative” part of the life cycle.

When speed of delivery of a project, even if only a partial solution in the form of smaller deliverable, is more important, then an incremental life cycle may be best.

That is the subject of the next post.

Characteristics of Predictive Life Cycles

I am going through the Agile Practice Guide, a collaboration between the Agile Alliance and the Project Management Institute (PMI).   It is being published in conjunction with the 6th Edition of the Guide to the Project Management Body of Knowledge (PMBOK).

The third chapter of the Agile Practice Guide is devoted towards distinguished the agile project life cycle from the three other types:  predictive (traditional or waterfall), incremental, and iterative.   The earlier posts I did on the chapter compare and contrast these four life cycles categories.   In this and the next three posts, I will review the next section 3.1 of the Guide which goes through and discusses each of these four life cycle categories in more detail, starting with the predictive life cycle.

The predictive life cycle takes advantage of the following characteristics of a project:

  • high certainty around firm requirements (with low degree of change during the project)
  • a stable team (that will be around for the duration of the project)
  • low risk

As a result, the project planning will be done as much as possible up front, and the project activities will often be executed in a serial manner (hence the nickname “waterfall” for this type of life cycle) as follows:

  • Analyze
  • Design
  • Build
  • Test
  • Deliver

When the planning is done up front at the beginning of the project, the constraints (mainly scope, time, and cost) can be articulated, and the project plan can be created to manage these constraints throughout the project.   Changes that might affect the scope, schedule, or budget need to be monitored and controlled a formal change control process.

The business value is not delivered until the end of the project, when the final product, process or result of the project is delivered.   If reason why changes are viewed negatively in predictive projects is that these will incur unanticipated costs, which may have a negative impact on the return on investment for the project, and thus changing its status regarding its strategic value for the company.

The next post will cover the characteristics of an iterative life cycle.

Planning in the Various Project Life Cycle Approaches

I’m going through chapter 3 of the Agile Practice Guide, which covers the four types of project life cycles, including predictive (traditional), iterative, incremental, and agile.  On p. 20 in a sidebar on planning in projects, it describes how planning is done for each of these life cycle approaches, and that is the subject of this post.

Planning is always done, no matter what the life cycle approach, that’s the first important point.   It’s not whether it is done, but how much planning is done and when.

  • Predictive (traditional or waterfall):  as much planning as possible is performed upfront.  Requirements are identified in as much detail as possible.   The team estimates when they can deliver which deliverables and performs comprehensive procurement activities.
  • Iterative:  prototypes and proofs-of-concept are planned, but the outputs are intended to be modify the original plans created in the beginning.   Earlier reviews of unfinished work based on input from the prototypes help inform future project work.
  • Incremental:  incremental initiatives plan to deliver successive subsets of the overall project.   Teams may plan several successive deliveries in advance or only one at a time.   The deliveries inform the future project work based on feedback from the customer.
  • Agile projects also plan.  The team plans and replans as more information becomes available from review of feedback from customers based on frequent deliveries.

The key point here is that the project requires planning–either upfront in predictive life cycle approaches or “plan as you go” in agile on the other end of the spectrum, with incremental changes to the product based on the interaction with the customers and the changes to the project based on the internal review done on a regular basis (the “iterative” part of agile).

The next series of posts is going to go into more detail into the characteristics of each of the four types of life cycles:  predictive, iterative, incremental, and then agile.