Waterfall Should Have Never Existed: Part 2

We left off in Part 1 of this article asking the question of HOW Agile and Critical Path could exist side-by-side in a single project schedule without affecting each other (much)? I laid out three dilemmas there are to resolve when you try to combine these two approaches that are different from each other but not each other’s opposites (as I argued in Part 1):

  1. The WBS of an Agile schedule is sprint-oriented (adaptive) with user stories within each sprint, whereas the WBS in a Critical Path schedule (predictive) is broken down in a deliverable-oriented way with activities within each deliverable.
  2. Agilists estimate in anything except hours, whereas predictive folks need the estimates expressed in hours to create their Gantt Charts and calculate Critical Path.
  3. Agilists don’t like identifying all dependencies between activities, but predictive people need all dependencies, the right types of dependencies and all entered correctly into their scheduling application. They need complete and correct network logic.

Let’s dig into the solutions I am proposing now, and remember that I’m suggesting a compromise to make combining BOTH approaches in ONE schedule work.

The benefit for this true hybrid approach of Agile and Critical Path is being able to manage your team using Agile (manage down) while managing your executives using Critical Path (manage up). Another use case is if one part of your project team wants to use Agile (software), whereas the others want to use Critical Path (hardware). This hybrid approach if useful for project managers that find themselves in the following situations:

  • You are building a hardware product (Critical Path) that has a software component as well (Agile).
  • You are designing a defense system with tangible components (Critical Path) and software components for intelligence gathering and processing (Agile).
  • You are building a software application (Agile) for a client that expects a full tally of the cost and a firm target date for delivery as captured in a firm-fixed price contract (Critical Path).
  • You are a contract research firm that is performing the clinical study for a new vaccine and needs to create the database and software interfaces specific to this research (Agile), as well as accomplish the purchasing, configuring, and distributing of hardware devices across the world to capture the results of the clinical study (Critical Path).

These are just some examples of how you might combine Agile and Critical Path (CP) in one schedule. Let’s solve the dilemmas to make this work.

Solution 1: WBS for CP and Agile

By tagging each line item (activity or user story) in the WBS and using the grouping feature in your scheduling software, you can easily convert one WBS to another. You can do this in Microsoft Project, Primavera, and most other scheduling applications. Let’s take a look at the Critical Path view with a deliverable-oriented WBS (with deliverables, activities and milestones):

Note that each line item (activity) has been tagged in the field Sprints with one of labels Sprint 1 – July, Sprint 2 – August, or Sprint Backlog, which allows me to create the following Agile view using the Group By feature in the same project schedule in Microsoft Project, as shown below with all activities allocated to the sprints and backlog:

Solution 2: Converting Agile Estimates to Hours for CPM

I once faced having to shorten the schedule of an Agile project for a team that was on the Critical Path of a highly visible, business transformation program at a financial institution. They were managing the data migration from an old system into a new one and presented a schedule that was half a year long. A similar endeavor had taken only three months ten years earlier. It was clear that the executive would not tolerate extending the duration of the program unnecessarily. I offered the option of taking on more team members, but the Agile team did not want a larger team, because that was not ‘Agile’ enough. I reacted in an ‘agile’ way to this ‘Agile’ team’s objection by proposing the start of a second Agile team working side by side with the first. The second team would take half of their workload and shorten their project by roughly half, but they did not want this either … until some executives overrode their objections. ‘Agile’ dictates that you keep the team size constant so that team members get to know each other and learn each other’s strengths and weaknesses. Agile empowers teams by having them self-assign all activities, which can optimize the allocation of assignments and results in a constant stream of productivity (called ‘velocity’ in Agile).

Clearly, the dilemma of reconciling different types of estimates is tougher to resolve, but here is the solution I eventually found that is based on keeping a team size fixed. Let’s say that your Agile team consists of a fixed number of people—ten. You have an Agile project with sprints of one month each. Each month is about 4 weeks of 40 hours/week or 160 hours per team member. So, you have 10 team members * 160 hours per month resulting in 1600 hours per month.

Let’s assume that the Agile team accepted a total of 800 points into their first sprint of one month long. We know that each point converts into two hours of effort (=1600 hours / 800 points), and we can now convert Agile estimates into hours of effort. We can create a Gantt Chart and have Microsoft Project calculate the Critical Path (provided I have entered the dependencies). You can see this in the previous illustration where each Agile estimate in the column Agile Points is converted using a custom-built formula (using a conversion factor of 3.87 for this particular project). You see the results of this calculation in the column Hours (Agile Pts. * 3.87) that was created using one of the extra number fields (like Number1, etc.) and the customize fields feature accessible from the ribbon (Format, button Custom Fields to enter a Formula).

Finally, these calculated effort estimates are copied for this sprint from the formula field and manually pasted into the out-of-the-box Work field while either:

  • Keeping the task Type to Fixed Durations (and Effort Driven is No) if you want to see how many team members need to be allocated to each activity, or
  • Keeping the task Type to Fixed Units (and Effort Driven is No) if you have assigned the resources already and want to see the durations calculated by Microsoft Project. In this case, you may need to make some tweaks to the durations (if they extend beyond the fixed duration of the sprint).

You’ll now have a schedule that started with Agile estimates, but also has the estimates in hours—person hours in the field Work and business hours in the field Duration. You need the Durations to build the Critical Path schedule a.k.a. a Gantt Chart.

The velocity for a team with a constant number of members typically stays constant over time (across the sprints), and the number of points accepted into each sprint will also stay relatively constant after the third sprint when the proper velocity has been established for that team. The conversion factor can be adjusted after the first few sprints, if needed, because the resulting hours need to be copied into the Work column on a sprint-by-sprint basis. So, for each sprint you can determine a new conversion factor and adjust the formula. In most Agile projects, you don’t need to adjust the formula any longer once the velocity has stabilized after the second or third sprint.

No Solution 3: Compromise Needed

As the project manager addressing the question ‘to link or not to link,’ I simply request that the Agile team works with me and helps me sort out the dependencies between the activities (or user stories) in the sprints and in the entire backlog. I create a complete and correct network logic for all WBS-items, and this has, so far, been a reasonable compromise for all Agile teams to make. At least for the ones, I have met so far.

With these three dilemmas addressed, organizations can make both approaches co-exist in ONE schedule, which allows one to happily switch from an Agile view of the schedule (when presenting to my Agile team i.e. managing-down) to a predictive view of the schedule (when I present to executives i.e. managing-up or managing‑out to clients). Switching views takes two clicks of the mouse, and in short, I manage‑down with adaptive Agile and manage‑up with predictive Critical Path.

I also manage-in and relax by keeping a handle on the overview and avoid the stress of a difficult situation where different stakeholders pull me into different directions: i.e. my team wants to be managed in an Agile way, whereas executives that pay my salary, want forecasts.

If you would like to learn more about how to convert an Agile schedule to a Critical Path schedule or vice versa, please refer to my textbook ‘Forecasting Programs’ (see this website: Books – ProjectPro Corp). Chapter 3 is entirely dedicated to this topic. To explore the Microsoft Project schedule from which I created the screenshots in this article, download the ZIP-file and Microsoft Project schedule from our website at Articles – ProjectPro Corp.

Thanks for reading both parts of this article Part 1 here if you missed it).

Please leave any comments you have below. I have made some daring statements and have summarized the last 30 years in the way I see them. I look forward to hearing what you agree and disagree with in this series of articles.

Written by Eric Uyttewaal
Eric is a thought leader on project, program, and portfolio management. He spends most of his time using software from Microsoft. He has authored seven well-known textbooks including ‘Forecasting Programs,’ 'Forecast Scheduling with Microsoft Project 2010/2013/Online,’ and ‘Dynamic Scheduling with Microsoft Project 2000/2002/2003.’ He founded ProjectPro, which specializes in Microsoft Project, Project Server and Project Online. Eric developed several Add-ins with his team that enhance the capabilities of Microsoft Project in creating better schedules (Forecast Scheduling App), managing cross-project dependencies (CrossLinksPro), identifying and documenting the Critical Path (PathsPro) and creating S-curve reports (CurvesPro). He was president of PMI-Ottawa in 1997. Eric has received awards from PMI in 2009, from MPUG in 2012, and from Microsoft from 2010 until 2017 (MVP).
Share This Post
Have your say!
00
5 Comments
  1. Eric,
    I find your logic and the solution to be well thought out and reasonable. as usual. In most situations that I have work in, Agile work is tracked in detail in tools such Microsoft TFS/DevOps, Git, or similar solutions and replicating the work package level detail in a MS Project is counterproductive as it introduces a high level of duplicate data entry. We use a simplified waterfall-ish solution listing only the necessary schedule items per sprint with all of the work as a single track-able task to capture schedule and cost data, but not the detailed user story/work items. Those are already captured in another system.

    • Hi Mark, Yes, many software shops would have another system like the ones you mention for keeping track of user stories and bugs. If that is the case you need to find a higher level of detail for your Microsoft Project schedule. You suggest to have a single task for each sprint, which will create a very high level schedule with only a few line items. If this meets your needs, please do so. It would not be a forecast schedule since each sprint will always end on its fixed date, so that benefit will not apply to schedules like that. What benefits is your organization looking for from its Agile schedules?
      I would suggest that you consider keeping your Microsoft Project schedules on a medium level of “features” or “functions” and still use it to predict the software project. What do you think of that?

  2. Eric – The suggestion to Mark about keeping the sprint tasks at a higher level is how we have been handing this in our CPM and EVM controlled schedules but it doesn’t reflect the dependencies/flow of work very we’ll in the plan. We often end up with horse-race sprint work packages when all budgeted scope is not accomplished in sprint 1 but sprint 2 begins as stories move from one sprint to another. This forces breaks in the serial logic and impacts the validity of the Critical Path. Any suggestions on making Agile, CPM and EV all effectively work together? Thanks for the great article!

  3. Thank you for the food for thought, Eric.

    I struggle with a similar problem w/ regards to Agile – referring to what Steven had described. The flexibility “embedded” in Agile (e.g. deferring incomplete user stories) results in though adjustments to the CP schedule. In fact, it’s hard to call this “managing executives using Critical Path” as they would expect a CR after CR normally. Such a schedule is simply extremely volatile. I doubt any gantt chart has an answer to that, but I’d love to learn about your take on this general issue. There is, after all, a discrepancy with the approach to managing scope between Agile and “more traditional” practices.

    My hope is that we find a “golden mean” here, i.e. to be able to provide our stakeholders more stability w/ regards to forecasting and yet enough agility at the same time. Best of both worlds, so to speak.

    • Hi Lech, Other than the suggestions and the approach I suggested in the article, nothing else comes to mind.

Leave a Reply