When to Use Agile, Waterfall, Iterative or Incremental Project Life Cycles

– Back to the Agile Practice Guide (all) –

Project Development Lifecycles

Project Life Cycle Deep Dive!

Do you know when to use Agile, and when to use Waterfall?  Do you know the difference and benefit of using iterations versus increments, or both?  From the Agile Practice Guide from the Project Management Institute (PMI) and Agile Alliance, we look at the four types of Project Lifecycles and the best times to use them.

Check out the video below now!

We’re looking at the characteristics of project life cycles from the Agile Practice Guide from the Project Management Institute and Agile Alliance.

Previously we’ve looked at the different types of life cycles.  We’ve got the predictive life cycle which is your traditional waterfall approach – very step-by-step.

We’ve got an iterative approach where we’re iterating, and we’re not necessarily releasing something but we’re getting feedback on a regular basis, usually every two to four weeks.

Then we’ve got the incremental life cycle and that is where we’re actually delivering an increment to something usable that a customer can can use see feel and touch and getting that feedback as well using that approach.

Lastly the Agile approach which is both incremental and iterative so we’ve combined those two things or we’re iterating towards success building that feedback back into the product but also releasing that product on a regular basis to refine that work and to deliver frequently.

So let’s delve into the characteristics of these life cycles a little more deeply.

Every project has characteristics around requirements delivery, change and goals and understanding the different types of lifecycle you can choose the right one for the circumstances of your project.  As we saw previously there are many different circumstances around projects they could be small large you could have different types of management styles you could have different types of organizations different types of products different types of customers and many many different things will influence how a project is ultimately delivered to the end result.

So we’ve got our items down the left hand side and the first one is Predictive – the requirements are fixed so we know very clearly what our requirements are going to be the activities are performed once for the entire project so they go along that nice straightforward approach it’s a single delivery right at the end and the main goal is to manage the costs as we’re going along this single file process with that predictive lifecycle.  It’s also known as the waterfall lifecycle so it takes advantage of high certainty we’ve got a lot of certainty around the requirements, we’ve got a stable team and there’s really a lower risk involved as a result of project activities often executing that straightforward serial manner step by step.

We’d go through things like kicking off the project creating the project management plan, gathering the scope and requirements doing the schedule cost risk all of those things in a step-by-step manner from a project management perspective as the team progress is through that detailed plan then they monitor and control changes that might affect the scope schedule or the budget and typically these projects won’t deliver any business value until right at the end of the project so we’re analyzing right at the beginning we’re designing the product right they’re building then testing and ultimately delivering all in that sequential manner.

Now what about the iterative approach?

First of all the requirements are dynamic so they will change.  The activities – we repeat those activities until they’re correct, so we go over them, we check them out then we go over them to improve them, check them out again and improve where we need to.  We still have a single delivery so we’re not making frequent deliveries it’s still that single delivery but it’s just repeated until it’s correct.  And the goal is ultimately the correctness of the solution.

With our iterative life cycles it improves the product or the result through successive prototypes so it’s essentially prototyping or proof-of-concept where each new prototype yields new stakeholder feedback and team insights.  So we’re improving, getting that feedback, improving, getting that feedback and we’re iterating towards success.

Teams may use time-boxing on a given iteration of usually two to four weeks to build and gather feedback and then put that feedback into the next iteration to improve again and this is really useful when the complexity is high or the scope is subject to change as the project is going along.  Iterative life cycles do take longer as they’re optimized for learning and gathering those requirements and getting feedback on those requirements rather than the speed of delivery so it’s not the same as our predictive approach because we’re analyzing all the way up front but then when we’re analyzing and designing the product then we’re prototyping and getting that feedback here and when we’re building and testing the product then we’re refining that as getting that feedback continuously on each iteration as well but we’re still delivering in one Big Bang at the end.

Next let’s look at the incremental approach.

The requirements for this are dynamic – they will change so they they’re still changing requirements over time, the activities are performed once for a given increment but we might have many different increments.  The activities are just performed once per that increment that we’re delivering so the delivery is frequent smaller deliveries in other words and the goal of this approach is speed we’re getting something to market we’re getting an increment delivered as soon as possible with incremental life cycles when businesses or initiatives cannot afford to wait for everything to be completed then they can deliver in increments something that is still complete enough to be used but not the whole product necessarily in this situation.

The customer, the business or the sponsor they’re willing to receive a subset of the overall solution delivered in frequent small releases now you could provide a single feature at a time for example and increments are time boxed in iterative methods still so usually they are you know they’re delivered on a frequent basis or they can also be pulled in a flow based method like Kanban for example if you’ve got your Kanban board where we’ve got the backlog on the left and our cards move across that Kanban board all the way to done. then the team pulls those cards as they have capacity to do so and work on them all the way until they are complete.  So that’s the other method that you can use when you are delivering increments and as you can see we’re doing all of those steps analyzing, designing, building, testing and delivering the increment for that particular increment and then we’re doing it again as we deliver another piece and another piece after that.

Now let’s look at the Agile approach.

The Agile approach the requirements are dynamic as well, they will change.  The activities are repeated until correct so they’re sort of an iterative approach there but also we’re delivering small deliveries, so frequent small deliveries so it’s incremental in that way because we match up to the frequent small deliveries but it’s also iterative in the way that we are repeating those activities until they are correct.  We’re putting feedback back into the process so because of that we’re combining those two things to get the most customer value and that’s our goal via frequent deliveries and frequent feedback.

With Agile life cycles in an agile environment the team expects the requirements to change so we’re not actually going into it thinking that everything is stable we know on the outset that things are going to change, and we’re prepared for that and that’s why we’re taking the agile approach.  Iterative and incremental approaches work together in an agile lifecycle to provide that feedback for planning the next iteration of two to four weeks and also uncovering hidden or misunderstood requirements so using those increments getting those in the hands of our customer then they can see feel and touch the product and you know they may actually have thought of something by using it that they didn’t think of before.

When we’re using Kanban or flow-based agile its iterated for the number of features that are work-in-progress.  So in other words with our agile board in our backlog as we saw before we might have 20 items in the backlog so the team pulls those features from the backlog column on the Kanban board based on their capacity and as you can see we’re iterating but we’re also delivering increments and we’re looking at the requirements analyze, design, test, to build – iterating that but also delivering that through small increments for our customer to see feel and touch.

Typically with an agile lifecycle the customer satisfaction is the goal and the customer satisfaction increases because we’ve got early and continuous delivery of value even though it’s only in small increments the customer is able to see that value early on and they’re able to use it so this incremental functional deliverable that provides value is the primary measure of progress so where that is the how we know whether we’re succeeding or making progress is by delivering those increments and continually delivering those increments to our customer.

Now lastly there might be circumstances in fact it’s probably most likely that you’ll be in a circumstance where you’ll have a hybrid approach.  In other words you have some predictive or linear approach combined with some iterative or incremental or agile approach in the way that you’re doing the work or a certain product.  Projects will often combine the elements of different approaches or life cycles in order to achieve their goals, just depending on the circumstances.  A combination of predictive iterative incremental and agile approaches becomes that hybrid approach, for example you might have a largely Agile approach with some predictive where you’re integrating an external component developed by a different vendor.

Maybe you’re using an agile approach, incrementing at certain two to four week iterations but then you’ve got a third party delivering something over here and you can’t actually see into their process so they’re just going to have that delivered in one go which is your predictive model.  Often that can just go in when it’s finished as one of your iterations, as part of your overall solution at the end of that so that’s how those two would work together.  In other words the single iteration might be required after their component is delivered to you in one Big Bang.

Now there are other scenarios as well so we might have a predominantly predictive approach with some agile components for example if you’ve got a straightforward project like a shed but you’re trialing a new roofing material for example then you might want to deliver an increment of that or iterate until you get it absolutely correct.

You could also have a combined predictive and agile approach where you’ve got a normal linear project but where tasks are tracked using a Kanban board and maybe daily scrums as well – they’re used for updating the work.  This is really common.  So you’ve got a normal linear project, say it’s delivered over a year but your team does use some of the some of the tools of agile where you’ve got the Kanban board and the backlog of work and you’ve got the 15-minute daily standup so that everyone is on the same page and you can help remove blockers and all of those practices that an agile team will perform even though it’s delivered in one big bang right at the end.

These are the different life cycles that you might encounter in project management and particularly as you move to an agile approach.

– Back to the Agile Practice Guide (all) –

Get the Leadership Card Deck:

Leadership CardsView All The Leadership Cards (48)

- or - Have the Leadership Cards delivered for your next meeting

 

Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable. You can get the whole book on Amazon here and enjoy your own copy.

2 thoughts on “When to Use Agile, Waterfall, Iterative or Incremental Project Life Cycles

  1. Great article, thanks for sharing! Would you only use the agile approach when the requirements change, or in other cases as well?

    – Paul, HUSH Project Management & Consulting Ltd.

    1. Great question Paul!
      Agile works well when we expect the customer requirements to change (or evolve), or when we absolutely have to ensure the customer is happy with what we’ve produced. A great example is link – four different Star Wars films, managed in either Waterfall or Agile style, and their results 🙂
      https://www.youtube.com/watch?v=TZyICwRlWdw

      Cheers – Dave

Comments are closed.