Predictability, Forecasts, and how it relates to Trust
In today’s world, predictability and reliability are key factors that determine trust between teams and their stakeholders. Stakeholders often need to know when a particular feature or product will be delivered. While teams have access to various tools for making such forecasts, the way they communicate and act on that information is crucial in building trust. In this post, I’ll explore how transparency, inspection, and adaptation are essential for creating a culture of trust within Scrum teams and with their stakeholders.
Note: This post was initially published in the Serious Scrum publication on Medium.
Buying Furniture
We recently ordered furniture from two different shops. Both shops gave an estimate of when the furniture would arrive. However, only one week after we ordered, Shop 1 reached out telling us they have delays and that there is a new estimated delivery date two weeks after the original estimate. From Shop 2 we heard nothing of that sort.
Even after the target date, we still had not heard from Shop 2. I reached out to them and ask about it, only to hear an “oh yeah, I’ll clarify this with the supplier”.
Two days later they told me that the furniture will arrive in approximately four weeks. I wondered if they would ever have reached out to me about this or not.
Trust, Gained and Lost
While both Shops are “late” based on their initial estimate, I trust that Shop 1 will deliver the furniture on the updated date. As they informed me quickly about the delay and I haven’t heard from them since. They have shown that they’ll let me know quickly if something comes up, so no reason to doubt the new target.
Shop 2, on the other hand, has lost my trust by staying quiet and letting me believe I would get my stuff on time. So while I got a new date from them, I don’t think I’ll have faith that they’ll deliver it on time.
How does it relate to Software Development?
“When will I get my furniture?” is a similar question to what a stakeholder might ask when they would like to know “When will I get Feature X?”.
In many cases, the development of a product resides in the complex domain and it’s best use an empirical approach such as Scrum to develop it. In this case, making predictions is hard, and our forecasts might be changing frequently.
Prediction is very difficult, especially about the future
Nowadays many teams have embraced probabilistic forecasting. Those teams could use Cycle Time scatterplots to forecast when an individual item will be done, for example, “there is an 85% chance that we deliver this Product Backlog Item (PBI) within 10 days or less”.
Or the teams apply Monte Carlo simulations to predict what the chances are that a set of PBIs are done on a certain day or how many PBIs they’ll manage in a given time.
However, the point of this post is not to go into detail about the tools that are available and used. But what do we do (or don’t do) with those predictions.
Both of the furniture shops had some means to predict initial delivery dates. Maybe the even used the same tool for this. But they behaved differently and this is what made a difference to me as their customer.
Transparency, Inspection & Adaption
I’ve seen that teams might use a way to forecast (MC Simulations or any other way). Those forecasts are even updated often. However, it’s important that this data then is made transparent. Within the team, but also with the stakeholders.
Transparency enables inspection — Scrum Guide 2020
The Scrum Events can and should be used for inspection. Is the forecast predicting that we won’t manage to achieve our Sprint Goal with the current plan? Sounds like a nice discussion for a Daily Scrum.
Does the forecast show that it won’t be likely to deliver this feature for an upcoming fair? The Product Owner most likely would want to raise this with the Stakeholders. The Sprint Review provides a formal opportunity to have this discussion. If it can’t wait till the Sprint Review, the PO should raise this sooner.
Inspection enables adaptation. Inspection without adaptation is considered pointless — Scrum Guide 2020
Simply mentioning the facts (like Shop 1 did) is better than not saying anything. But we have the chance to collaborate in the team and with the stakeholder to adjust our plan. “Can we achieve the goal in a different way?” or “Does it make sense to release without this feature?”.
Once it is discovered that the forecast tells that something changes, it is expected that action is taken.
A Scrum Team is expected to adapt the moment it learns anything new through inspection. — Scrum Guide 2020
I believe it’s our duty as professionals to act on this information as soon as it becomes available.
Live the Scrum Values
While it might not be comfortable and requires some courage to reach out to stakeholders informing them about the latest development, it will in the long term help with your credibility.
They’ll learn about (and most likely appreciate) the openness and it will increase their trust in the team. If a team will “surprise” their stakeholders at the latest possible moment with some unpleasant news, that most likely won’t sit well. And trying to simply stay quiet and hope nobody notices (hello Shop 2) for sure isn’t a good idea.
The best forecasting tools won’t bring you any benefit if you’re not acting on the data they provide. I would go as far as call it unprofessional if you chose to ignore this data.
What Now?
If you have no way to forecast at the moment, I would start there. Being part of an agile team does not mean running completely blind. Most likely your stakeholders expect some kind of forecast anyway. You don’t necessarily need all kinds of fancy forecasting tools to get started. While I recommend learning about Flow Metrics and Probabilistic Forecasting, it might be enough to break down your feature into some potential Sprint Goals and reflect frequently if they are still making sense.
Note: A forecast is not a commitment. If we’re doing complex work, some surprises are to be expected.
Once you have some means of forecasting, start to update and check them frequently. As soon as you see something change, start having some open conversations about what you learned and how you might be going to adjust your plans based on this information.
Use your Scrum Events to make your updated forecasts transparent, inspect them together with the team and stakeholders and adapt your plans as needed. In Daily Scrums you can talk about your Sprint Goal and the changes to your plan to achieve it. And in your Sprint Reviews, you can discuss the Roadmap and your forecasts with your Stakeholders.
Conclusion
Getting stakeholders to trust a team is no easy feat. Continuous forecasting, for example using Monte Carlo simulations, is a tool that can help you with building trust with stakeholders. Either you gain it by consistently delivering on according to your forecasts. Or you have a chance to show openness and inform them early about a new development.
If you are using such an approach, make sure to apply the three pillars of empiricism: transparency, inspection, and adapation.
If you don’t make your forecasts transparent, you miss an opportunity to inspect and adapt. And if you inspect them and learn some new information, make sure to share this with your stakeholders and adapt your plans accordingly. This will help the team build trust.
Additional Resources
If you want to apply probabilistic forecasts, I would suggest to check out
Actionable Agile Metrics for Predictability: An Introduction by Daniel Vacanti
When Will It Be Done?: Lean-Agile Forecasting to Answer Your Customers’ Most Important Question by Daniel Vacanti
Drunk Agile Youtube Series by Daniel Vacanti and Prateek Singh
The Kanban Guide for Scrum Teams from Scrum.org