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.

Life Cycle Selection–Degree of Change vs. Frequency of Delivery


I am taking notes on the Agile Practice Guide, a companion volume to the 6th Edition of the Project Management Body of Knowledge developed by the Agile Alliance in partnership with PMI.

I’m starting the third chapter on Life Cycle Selection, which contrasts agile methodologies with other project management life cycles, including predictive (traditional), iterative and incremental.   It’s only after making this distinction clear in the third chapter that the Agile Practice Guide will go on in the next chapter how to create an agile environment.

I really appreciate this chapter because I am not familiar with incremental and iterative life cycles.   In the 4th edition of the PMBOK Guide, agile was not even named (it was called an “adaptive” life cycle).   In the 5th edition of the PMBOK Guide, the life cycles were named but the distinctions were only mentioned in the introductory chapters–the rest of the Guide dealt with the processes of the traditional or predictive life cycle.

Agile has grown so much that a project manager needs some familiarity with it, so the 6th Edition of the PMBOK Guide actually has small sections in each chapter showing how the content can be adapted for an agile environment.   And another improvement I see in this introductory chapter is that it spells out the differences in the characteristics of the various project life cycles a lot more clearly

In the 6th Edition of the PMBOK Guide, in Figure X3-1 of Appendix X3, the Iterative and Incremental life cycles are listed on a one-dimensional continuum like this:

Predictive  ————-  Iterative ————- Incremental ——————–  Agile

However, in the Agile Practice Guide, the Continuum of Life Cycles is explained using a two-dimensional square, as shown in Figure 3-1 on p. 19 of the Guide, with the two variables being degree of change and frequency of delivery to the customer.

The four life cycles are contrasted below in terms of these two variables:

  • Predictive–projects that have a low degree of change and a low frequency of delivery to the customer.   In this case the reduced uncertainty and complexity allows teams to break work down and put in into a sequence that is predictable.
  • Iterative–for a project that has a high degree of change (but a low frequency of delivery to the customer), an iterative approach allows feedback on partially completed or unfinished work to improve and modify that work so that it is repeated until correct.
  • Incremental–for a project that has a low degree of change but a high frequency of delivery to the customer), an incremental approach provides finished deliverables that the customer may be able to use immediately.
  • Agile–for a project that has BOTH a high degree of change AND a high frequency of delivery to the customer, an agile approach leverages both the aspects of iterative (repeated until correct) and incremental (frequent smaller deliveries) characteristics.  When teams use agile approaches, they iterate over the product to create finished deliverables.  With each iteration, the team gains early feedback and provides customer visibility, confidence, and control of the product.   Because the team delivers the highest value work first, the project may provide an earlier return on investment.

In the next post, the four life cycles will be compared and contrasted with how they deal with the concept of planning.  

 

Introduction to Life Cycle Selection


This series of posts is my set of notes on the Agile Practice Guide, a collaboration between the Agile Alliance and the Project Management Institute (PMI) as a supplement to PMI’s Project Management Body of Knowledge of more traditional project management methodology.

The current chapter I’m reviewing is chapter 2 on an introduction to agile, and the final section is a bridge to the next chapter 3 on Life Cycle Selection.   It contrasts agile to other types of life cycle such as predictive (i.e., traditional), iterative and incremental in terms of the rationale for choosing those other types of life cycle.   The choice usually comes down to one of two factors:

  • degree of uncertainty of technology
  • degree of uncertainty of requirements
  1. PREDICTIVE–Projects which have a low degree of uncertainty in terms of BOTH technology AND requirements, or to put it another way, projects which have clear and stable requirements and clear technical challenges with little difficulty can use a predictive life cycle.   This is where the bulk of the planning occurs up front, and executing occurs in a single plan in a highly sequential process, hence the alternate name of a waterfall methodology.
  2. ITERATIVE–An approach that allows feedback for unfinished work to improve and modify that work.   This is used if there is uncertainty in terms of the requirements so that these can be refined through the process of increments.
  3. INCREMENTAL–An approach that provides finished deliverables that the customer may be able to use immediately.   This is used if there is uncertainty in the use of technology because is focuses on that which is actually reliably useful (focus on quality).
  4. AGILE–An approach that is both iterative and incremental to refine work items and deliver frequently.

Iterative and incremental methods have evolved to reduce waste and rework because they add:

  • Very short feedback loops
  • Frequent adaptation of process
  • Re-prioritization
  • Regularly updated plans
  • Frequent delivery

Projects that have a low-to-medium level of uncertainty in terms of technology and/or requirements are considered COMPLICATED, and those that have a medium-to-high level of uncertainty level of uncertainty in terms of technology and/or requirements are considered COMPLEX (see the Stacey Complexity Model diagram in Figure 2.5 on p. 14 of the Agile Practice Guide).

Agile combines elements of iterative and incremental methods and works well for projects that:

  • Require research and development
  • Have high rates of change
  • Have unclear or unknown requirements, uncertainty, or risk
  • Have a final goal that is hard to describe

By building a small increment and then testing and reviewing it, the team can explore uncertainty at a low cost in a short time, reduce risk, and maximize business value delivery.

This uncertainty may be centered on three characteristics that typically have elements of high uncertainty:

  1. Product specification (is the right product being built?)
  2. Production capability (can the product be built this way?)
  3. Process suitability (is this an effective way for the team to work?)

However, if the degree of uncertainty of technology and/or requirements goes from high to very high, the project goes from COMPLEX to CHAOTIC, and may reach the limits to which project management can reliably deal with the project.   One of the variables (requirements or technology) needs to be contained in order to be able to deal with the project using a suitable life cycle.

This post is merely an introduction to the topic of project life cycles.   The next chapter, chapter 3, goes into the contrast between agile and the other three types of life cycles, predictive, incremental and iterative.  It is only after this chapter discussing the differences between these life cycles that the agile practice guide will focus on agile itself in terms of how to create an agile environment.

 

 

 

The Relationship of Agile and Lean (continued)–the example of the Kanban Method


In my review of the chapter 2 of Introduction to Agile of the Agile Practice Guide, I am constantly surprised by the insights I’ve gained into the world of agile.   Of course I was expecting to learn about the history of agile which I got with the history of the Agile Manifesto and the 12 agile principles that are the underpinning of the agile mindset.

However, I didn’t expect that the Agile Alliance would consider that agile, coming out of a software application area, would consider itself a descendant of lean thinking, which comes out of a manufacturing system.   But as it explains on p. 12 of the Guide,, this shared heritage is similar because it focuses on

  • delivering value (and eliminating that which does not add value)\
  • respect for people
  • being transparent
  • adapting to change
  • continuously improving
  • focusing on the best outcome regardless of the approach used

The Kanban method is inspired by the lean-manufacturing system and emerged in the mid-2000s as an alternative to the more formal agile methods that were prevalent at the time.  I had the pleasure of coaching a speaker at the PMI Global Project Management Conference held in Chicago at 2017 who spoke on Kanban methods.   I coached her not because I was an expert on Kanban but because I was a member of the PMI Chicagoland Toastmasters club and as a Distinguished Toastmaster, I offered to help those speakers at the conference who were delivering a talk for the first time and wanted some pointers about how to present their talk in such a way to get their content across in a way that would project confidence and engage the audience in their material.

What I got out of the experience was how much fun the Kanban method was for people who participated in it.   I’ve heard project management called a lot of things, but fun was rarely an adjective used to describe it.  But it was because it was transparent, and people got to react to people, and not to processes, that it became so much more a human endeavor.   That’s why I took out of her talk, and that’s what increased my interest in its relationship to agile project management.

On p. 13 of the Agile Practice Guide, it says that the Kanban Method is the original “start-where-you-are” approach that can be applied with relative ease, and that project teams can progress towards other agile approaches as they deem necessary or appropriate.

Although it was conceived in and around lean manufacturing, it is now widely used in agile settings.

Annex A3 of the Agile Practice Guide goes through more details of the Kanban Method, and I will cover that in a later post.

 

The Relationship of Agile and Lean


I am doing a project where I  going through all the points in the Agile Practice Guide in a similar way that I went through the contents of the 6th Edition of the Project Management Body of Knowledge (PMBOK) last year.

In my last post, I discussed the point about agile approaches vs. agile methods, where the former focuses on the internal approach or framework, and the latter focuses on the external practice or method.   The Agile Practice Guide tends to settle on the term “approach”, but the term “method”, “practice”, “technique”, or “framework.”

This post takes the focus one step back, so to speak, and shows the relationship between lean and agile.   Agile comes from the world of software development and lean comes originally from the world of manufacturing.   If you look at Figure 2-4 on p. 11 of the Agile Practice Guide, you will see that the Agile Alliance actually puts lean as a wider category that encompasses both the values and principles of the Agile Manifesto and methods such as Kanban.

Why?  Because they share lean concepts such as:

  • focus on value
  • small batch sizes
  • elimination of waste (i.e., that which does not add value)

The Agile Alliance says there are two strategies for fulling the agile values and principles outlined on pp. 8-9 of the Agile Practice Guide.

1. Adopt a Formal Agile Approach

This is an approach intentionally designed and proven to achieve desired results.   Take time to learn and understand the agile approach before changing or tailoring it.   Premature and haphazard tailoring can minimize the effects of the approach and thus limit benefits.

2. Achieve Progress on a Core Value or Principle

Implement gradual changes to project practices in a manner that fits the project context to achieve progress on a core value or principle.  Use timeboxes to create features, or specific techniques to refine features in an iterative manner.   For example, divide one large project into several releases.   The end goal need to be agile for its own sake, but rather to deliver a continuous flow of value to customers and achieve better business outcomes.

So you can head towards agile gradually or by adopting a more formal approach, but it needs to be done in a mindful way in any case.

The Kanban method is one which is used in manufacturing and software environments and therefore it merits a special discussion about its relationship to lean thinking.  Therefore it merits a separate post, which will come next.

Is Agile an Approach or a Method?


This is a semantic question that is being asked on p. 11 of the Agile Practice Guide.    The-Integral-Model-1

One way of making sense of this question is to use the heuristic device from Integral Theory of dividing the approach to any question into the four quadrants listed above.   If you look at a problem from the exterior, in terms of what types of exterior steps you take to the problem, then you are looking at it from the standpoint of a method.

If you are looking at a problem from the standpoint of the interior, in terms of what sort of interior mindset you take when looking at a problem, you are looking at an approach.

Figure 2.4 on p. 11 of the Agile Practice Guide shows several approaches, with “lean” being the largest category, and agile and the Kanban method being subsets of lean because they share some lean concepts such as “focus on value”, “small batch sizes”, and “elimination of waste.”

In studying agile, it is important to study not just the methods, but the mindset that produces them.   I remember asking one of the agile experts at a PM Symposium put on by PMI Chicagoland what he thought was one of the biggest misconceptions people had about agile who were coming from the traditional project management world.

He said, they take a look at the lack of documentation and they think that agile project management is undisciplined.   He said they don’t realize that it is disciplined, but that discipline is internalized, meaning that it exists within the minds of the people who are practicing the methods of agile, and is not always apparent to the casual observer.   Now in some methods, such as Kanban, the formality is more readily apparent because a lot of the action items and even the relationships are made visible, but it is still more informal than traditional project management because it is written on sticky notes that can be shifted around a lot more quickly than items on a spreadsheet.

But don’t be fooled into thinking that the lack of formality means lack of importance.   It is precisely because the relationships are not as formal, i.e., not as rigid, that they are more capable of responding to change, and THAT is one of the “superpowers” of the agile approach.

In the next post, I will discuss in a little more detail the way that the Agile Alliance describes the relationship between lean, agile and the Kanban Method.