Tracking Schedule Progress in Agile

Why

Meet Vince. Vince is managing a project with an aggressive timeline. He needs to go to production by the end of the year and time is passing pretty quickly. He doesn’t have a lot of scope flexibility so he is very interested to know “Are we on track to delivering the scope we committed to on the time we committed to?”. He wants any delivery risks to surface as early as possible so he can mitigate them.

Maybe you can relate to Vince or are working with Vinces in your organization. The challenge of knowing whether we are on track to deliver, especially with this agile myth in the background that we cannot know or shouldn’t even care is haunting many project/program/development managers at various levels as their organizations take on agile approaches to product/project development.

Current approach in waterfall/Critical Chain Project Management projects

In waterfall or any classic task network based project management approach we answer the question “are we on track?” by looking at the task network – checking off all the done tasks, seeing how much duration is left in the tasks in progress, and how much duration is there in the not-started tasks, and based on the dependency network between those tasks we can give a projected end date to the project. The state of the art in this style of project management is to add project and feeding buffers to protect against uncertainty while minimizing effects of Parkinson’s law (work expands to the duration allocated)

Idea in Brief

The agile alternative is to answer the “Are we on track” question by comparing the amount of “Done scope” to the total scope size. Since our work is done in end to end functional scope units (Features/Stories) this simple percentage gives us an accurate picture of the progress for all scope-related project activities.

Vince can use this approach to know where his project is, assuming he is managing it in flow mode meaning scope units get to “Done” early and often in a continuous fashion throughout the project. In order to make this happen Vince needs to work with his people to make the scope units granular enough so that they can be finished within days-few weeks. Vince should also lead a “Stop Starting Start Finishing” execution mode where there is a focus on a certain number of scope units at a time (Work in Progress level), leading to an ongoing pace of finishing units and starting new ones.

A snapshot view of this information gives Vince the % complete of the project. An historical view can gives him the trend of % complete which can indicate improving or deteriorating situation. This is typically portrayed in Cumulative Flow diagrams or Release Burnups.

Seasoned professionals in the product development world know that there is a lot of inherent uncertainty in the actual work. This leads to variance between the planned time it will take to do something and the actual time it takes. This uncertainty doesn’t disappear with agile development of course. The difference is that agile acknowledges this uncertainty and takes it on as one of the basic axioms of reality in any real life project. We structure our execution approach to respond to this variability in a couple of ways. Vince asks people to avoid buffering for variability in the day to day work/estimates. Vince instructs his people to simply complete work to the definition of done as fast as possible and pull new work as soon as we can. This reduces the effect of Parkinson’s law. Vince can also consider some other measures but he would be wise to see if this simple approach is enough before complicating his kanban system too much up front. (We will cover some more approaches later in the paper)

Vince still maintains a “project buffer” to protect against variability in the throughput. This works similarly to a Critical Chain Project Buffer in that Vince tracks incursion into the buffer and expects it to happen gradually in the project and if it happens too fast he knows he is at risk. ( In classic agile projects this buffer is a Scope Buffer meaning we have non-mandatory scope that we hope to get too if variability plays in our favor but can throw out if necessary in case the going gets tough. )

Slow Start

In the first weeks of project execution Vince is very concerned. His charts don’t show any progress towards completion and he is starting to itch for old style remaining duration/effort reports from all his people. What Vince needs to realize is that the amount of time it takes to start seeing progress is mainly a function of the Work in Progress (WIP) level – the number of scope items as well as their aggregate size. The higher the WIP the longer the cycle time from start to finish/done and the longer he will have to “stay in the dark”. While remaining duration/effort reports will provide SOME indication of progress for the open tasks it dangerously ignores the fact that the best measure of progress is working software and not progress reports. Vince should be focused on ensuring scope items are granular enough and that his team is focused on the right amount of scope items – both enabling faster completion of the initial items and establishing a repeatable project throughput trend.

When Vince talks to his friends Robert and Sandra he learns that their projects also provided some frightening moments at the beginning. They are all seeing an S-Curve like behavior in the first days/weeks. Vince looks at the S-Curve behavior from previous projects so he knows more or less when to become really worried that his problem is beyond the initial “Slow Start”.

A key tool Vince now uses to drive the right behavior in his project is the Cumulative Flow Diagram (CFD):

In this diagram we can see not just the completion rate (in red) but also each of the work in progress queues as well, over time. In this example we can see from left to right the flow of work from the Backlog through Design, Development, Test and finally Complete. When Sandra first shared this CFD of her first agile project with Vince and asked him what he saw Vince was dumbfounded, trying to see what this graph means. Then Sandra asked him to focus on the first days of the project. Looking at days 0-30, what can he see?

Vince said all he is seeing is the backlog, and a lot of designs starting. Basically design for 40% of the scope of the project is starting. Sandra agreed. This is exactly what will happen in the first days. We are starting things, and at first it will seem like there is no progress. Why? Because as long as the items are still in Design, from the perspective of the CFD they look at the same place. We only see an item change color and move towards completion when it moves a phase/lane on the kanban board. And the board at this stage would look something like this.

(Click on the image to enlarge it)

Then Sandra showed Vince the CFD a couple of weeks into the project:

Now Vince was able to see the beginning of flow – a somewhat steady pace of work starting to get completed. Sandra asked if Vince can predict what are the chances that this project would be finished within 250 days as planned. Vince took a marker and extended the red area of completion and tried to intersect it with the overall orange scope level.

(Click on the image to enlarge it)

“Seems like the project is not ending on time” answered Vince. Indeed, Sandra agreed that the intersection of the red and orange lines is at day 300 more or less. She asked Vince what he thinks the real completion would be. Vince said that based on his experience progress picks up after the initial ramp-up so he would expect the curve to go up over time. Sandra agreed that this is a reasonable expectation especially in a project with a fresh team and new environment/customer rather than an ongoing development/maintenance project.

At this point Sandra shared with Vince a couple of “Planned Completion” curves for the project and asked him what he thinks each curve represents and which curve he thinks matches HIS project.

(Click on the image to enlarge it)

Vince thought a bit about it. Then he said – “The red line represents naïve optimism. We will start to finish items on day one of the project and our throughput will be perfect straight out of the gate. Did you ever see a project run like that?”. Sandra laughed. Vince continued. “The green line is interesting. It reflects the fact that it will take time for us to start completing items so that sounds more realistic. I don’t like being in the dark but I expect my project might look something like this”. Sandra nodded and asked what Vince thought of the purple curve. “Hmmm. What’s different about the purple is that it seems like the pace is improved throughout the project and then slows down a bit at the end. So maybe it reflects the effect of ramping up and learning curves on one end and the slowdown at the end when the final touches need to be applied and we are blocked on few items and cannot really use our whole team effectively. This sounds even more realistic for my project”. Sandra agreed and reminded Vince of the “S-Curve” behavior noticeable in most projects. She showed the full CFD again and now Vince could see that basically the project was right on the purple curve most of the time. Sandra told him that once she realized this S-curve is the expected healthy behavior of her project she had a baseline to compare to. Every time the actual completion line was below the curve she knew it was a real risk eating into her Project Buffer. Being above the curve meant buying back some of her Buffer. Basically there is a yellow area around the curve which is the warning zone. Below it is the red danger zone and above it the green all-ok zone. 

(Click on the image to enlarge it)

Sandra also made sure Vince remembers that his best approach to improve visibility would be to reduce the size of scope items and/or work in progress – both leading to earlier and faster completion which provides better indication about the real throughput on the project earlier and allows you to see whether you are on the curve. Vince said he understands but that his people are telling him they cannot really break work down into smaller pieces and they cannot focus on fewer items. Something about hard to work on the same files due to the version control system, the overhead of visiting the same areas of the code multiple times. Sandra laughed again and said all teams start like that. What typically helps is to provide visibility and focus on the level of WIP - both the number of items in progress and their size (The kanban board can help with that), then collect examples of situations where it was hard to break an item or where it was hard to keep the WIP low. Every so often (e.g. bi-weekly) meet to retrospect specifically using this collection of exceptions/extreme cases. Brainstorm retroactively about what was the root cause behind the challenge to break/limit WIP and look at either ideas the team has or practices from the agile world such as Acceptance Test driven story slicing, Refactoring, modern source control systems or testing tools, depending on the specific challenge. Leaders such as Vince should give the team permission to spend time in this learning and experimentation and system improvement process if they want to achieve a better flow and lower WIP over time.

Vince starts to see the real implications/costs of agility and while he understands this might be a worthwhile investment he is wondering how he can get his people to change the way they are working quickly enough to enable agile tracking that works. Vince decides he will rally everyone around the need for visibility and predictability. He will convince his people that real visibility means more relaxed managers (assuming the progress is good!). More relaxed managers means people can focus on work rather than reporting and status meetings, which means faster progress, healthier project, and even more relaxed managers.

He realizes that the time/overhead required to provide a working software / CFD based visibility is minimal compared to other remaining effort based alternatives which can be another selling point that can help him. All the people need to do is make sure the status of each work item is reflected correctly. No need to say how many hours were invested or what is the remaining effort. And the lower the WIP the lower the overhead of maintaining the kanban board. There are fewer open activities which require active progress tracking.

Sounds like this breaking items to smaller pieces and working on fewer items at the same time is a change really worth investing in to make project management easier!

Conclusion

We saw that it is possible to track an agile project and manage its execution risks. We saw how real-world situations such as shallow agile implementations with high work in process can reduce early visibility/predictability and how this fear/uncertainty can be leveraged to drive towards smaller work items and lower work in process bringing the benefits of both better project risk management as well as more effective agile execution and learning.

If you are managing an agile project/program think about the WIP in your project, how your burnup/CFD would look like, and what you might want to do about it.

About the Author

Yuval Yeret leads the Kanban/Flow practice for AgileSparks, an international lean agile consulting company based out of Israel. He led several strategic long-term lean/agile initiatives in large enterprises and is one of the leading Kanban Practitioners and Trainers focused on the enterprise product development world. Yuval is a big believer in pragmatic, best-of-breed solution design, taking the best from each approach, avoiding Dogma, therefore it is not a surprise to find him among the leadership of the pragmatic and evolutionary Kanban movement. He recently received the Brickell Key Award for Lean Kanban community excellence, driving Kanban adoption in Israel. He published “Holy Land Kanban” based on his thinking and  his writing.