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.


How Hamilton Revolutionized The Broadway Musical–a lecture by John McWhorter

Dr. John McWhorter is Associate Professor of English and Comparative Literature at Columbia University.   He gave a short (12 minute 20 second) lecture in the Great Courses Plus series of lectures offered by the Teaching Company and I wanted to pen a quick note to say that I was impressed on how he compressed his main argument into such a short but powerful talk.

Hamilton bridges the gap between popular music and the music of theater

The music of Hamilton is revolutionary in an odd way, because it is oddly old-fashioned.   The music that the American public would hear in a musical fifty years ago such as Rogers and Hammerstein or the Gershwin brothers a generation earlier would be music that would similar to the popular music coming out of the radio and television.   As celebrated as the musicals of Sondheim might be, there was an increasing gap between the popular music coming from Broadway and modern pop music, to the point that it would be called something else, “show music.”

Rap has become the popular music for young people, and by using that musical style for its songs, Hamilton has become a “rap musical” if you will.   This means it is drawing in a younger audience into the theater who are listening to a story in a musical style that they don’t have to adjust to, and also causing an older audience who appreciate theater to relate to  rap in a way that they would not ordinarily have done.   So it is revolutionary because it is responding musically to a change in demographics in the American population.   Speaking of demographic changes …

Hamilton tells the story of revolutionary America from a revolutionary angle … that of people of color

The story of the Founding Fathers is told from the point of view of people of color, and the white person in it (the King) is the Other, and vaguely sinister.   The fact that this traditional story of our revolutionary origins told from a revolutionary new angle could become a popular hit tells us something about the shifting demographic of our nation.

People of color are not in the margins in this musical–they are front and center.   Twenty years ago, nobody would have been as interested in the story of Hamilton.   But now, people are saying, the fabric of our country has many threads, and we want to trace all of them.   It is not a rejection of the patriotism of an earlier age, it is a widening and deepening of that patriotism by finding other colors stitched into the national fabric.

Hamilton revives the promise of the American Dream

Although it is told in the guise of a fatherless immigrant from the Caribbean who rises to become one of the Founding Fathers, it is popular not just among those could be called Hamilton’s descendants, but all people who go can relate to the story of someone who transcends their origins to create a better life.

Before the Revolution, one of the most privileged of Americans was George Washington, but even he realized that the system was rigged against Virginia planters like himself.   After all, it was a colony of Great Britain, and it was seen by the mother country as a source of wealth to be extracted.   Americans, it turns out, had different ideas about building their own wealth, which is the outline of what might be called the American Dream.

For a generation now, the assumption for baby boomers that the life of their children would automatically be better like it turned out for their parents has often turned to be a disappointment; what if a musical came along and showed that such a life were possible, no matter what your racial or social origins are?   Well, why not?   We’re in a parallel situation to before the Revolution; but rather than colonized by Great Britain, we’re living in an economic situation as if we were being colonized internally.    What if the promise of the American dream, seen through the life of a fatherless immigrant, could spark the same revolutionary spirit today?

After Professor McWhorter’s talk, it made me want to get tickets for Hamilton before it leaves the Chicago area, that’s for sure!

NOTE:   This lecture on Hamilton shows another feature of the Great Courses Plus that is worth keeping the subscription up to date:   they regularly add lectures on topics that are relevant to today’s event’s or even popular culture.