Core to the Project Manager, Scrum Master, Product Manager, team, and stakeholders is
#2 Risk of missing the delivery schedule because of poor predictions
from a previous blog entry “Seven Risks in Software Development”.
On LinkedIn, I state as an Agile Project Manager I do this …
Improve your agile process, create reliable and predictable deliveries. I coach teams to use data and analytics that show how the workflow is actually performing. Which start conversations and inform actions resulting in measurable improvements.
A bold statement and not always easy to achieve. What is behind this?
I have distilled Daniel S. Vacanti’s work “Actionable Agile Metrics for Predictability” into my value statement and practice.
“Simply stated, flow is the movement and delivery of customer value through a process.”
The essence is to treat development as a process and be very clear on the start dates and end dates for all work items. And then use simple analytics and visualizations to see if you have a stable process. For example, is the scrum process being used actually stable?
And what exactly is stable? Vacanti answers this question very clearly by spelling out the
5 assumptions behind Little’s Law. You can see a stable or unstable process by using the analytics Vacanti recommends: Cumulative Flow Diagrams, Cycle Time Scatter-plots, and Cycle Time Histograms. Vacanti also warns, even if your process looks stable, it might not be stable. You must also make sure that the process is not accumulating flow-debt.
Once we have that stable (or near stable) process, that is when we can use Monte Carlo simulations on past performance, to make those accurate and probabilistic schedule predictions.
Example: we have a 85% chance that a user story accepted into a sprint will be completed in 20 days or less. That might be the Service Level Objective the delivery team uses with the business stakeholders for delivery agreements.
In this example, the only estimation required is being confident that the user story taken into the sprint can be completed within the time frame of the sprint. And we let past data and Monte Carlo simulations help us with lightweight planning and scheduling.
I have used this approach and it is great way to visualize the teams output and also start those improvement conversations.
As an Agile Project Manager, accurately stating the deliver schedule is often how the project’s performance is judged.
More from Vacanti’s book “Actionable Agile Metrics for Predictability”
Little’s Law, reframed for knowledge work, is Cycle Time = WIP / Throughput
Which tells us, for a stable processes, one lever we have is to reduce WIP to shorten Cycle Time and deliver value sooner to the customer.
Vacanti’s 5 assumptions for Little’s Law to hold, but in my words are …
- Work coming in = working leaving, on average.
- All work accepted into the process is started and eventually completes.
Note: we can have a tag for abandon work, when we know we must remove the work item because it will not be delivered, either because the work item “never will be delivered now” or “will not be delivered in the foreseeable future”.
- The amount of WIP is about the same, at the beginning and ending of the time interval being measured.
- Do not allow WIP to arbitrary age inside the process. That is, work that is accepted into the process, does not stop very often. It may stop because of an outside dependency. It may stop because of a “self inflected process wound” by stopping work on an active item, to service a higher priority work item recently introduced.
- Must use consistent measurements for all three variables: Cycle Time, WIP, and Throughput
Vacanti provides many great metaphors in his book.
- Airport arrivals and departures — what would happen to an airport if the aircraft arrival rate was constantly greater than the departure rate?
- Airport security lines and the effect of special queues (e.g., prescreened passengers) has on the average wait times for the regular queue in small airports where there is only one security agent attending all queues. Good luck making your flight if you are in that “punter” queue.
- Is the process you are managing a Ponzi scheme?
Yes it might be a Ponzi scheme, if resources are taken away from active work-items to service new work-items more often than not. No wonder business stakeholders get frustrated with delivery teams, even though these stakeholders are often the primary source of new, high-priority work-items.