Forecasting Reality: The Power of Truth-Telling
We’ve all been there…scope and schedule have been planned, work has begun, time has passed and now your leaders are asking for an update, but what they really want is for you to tell them that everything is on track and exactly as originally planned. This leads to miscommunication, disempowerment and undermining of the team. Scrum teams struggling with leaders who are reluctant to empower them would do well to start with this question: How often do you update your leaders, truthfully, given the information that you have available, on how long it will take to reach your next goal?
Many Scrum Teams fear the repercussions of communicating scope or schedule changes to their leaders and stakeholders. They believe that telling it like it is will lead them to appear incompetent or unable to execute reliably to plan, so when plans change there’s a tendency to pretend as though earlier projections remain on track. They believe that delaying updates or embellishing the current status will buy them just enough time to bring the work back on track and in alignment with the plan. Unfortunately, the opposite is usually true: the work diverges even more, relative to the plan. In complex adaptive environments, reality has a way of drifting further and further away from initial projections over time. To make matters worse, the false narrative that “we’re on track with initial projections” spreads quickly across all levels of leadership through the game of telephone that hierarchical organizations tend to play. When this happens, not only have Scrum teams been untruthful with their leaders, but their leaders have unwittingly become accessories to the untruth by sharing it with others.
This is a self-fulfilling prophecy - by fearing to be truthful, a situation has emerged where communicating the truth can now lead to genuinely negative consequences. Eventually, the day this team planned to achieve their goal will come and the organization will learn the truth about their progress. The house of cards will come crumbling down. Leaders will punish this team for making them accomplices in the lie either explicitly on performance reviews or implicitly through falling out of favour and assigning them less important work. When this happens, the belief that telling the truth leads to negative consequences is reinforced so the team finds increasingly clever ways to communicate that their next goal is on track when, in reality, it is not. In systems thinking, this is called a negative reinforcing feedback loop and unfortunately, it's playing out in agile organizations everywhere.
What isn’t always obvious is that by reliably sharing the truth every sprint, something paradoxical and magical happens. We enter into a new loop, but this time it’s a positive reinforcing feedback loop. When teams communicate changes to the forecast every single sprint, leaders don’t get upset or view them as incompetent because the changes that are being communicated are small enough that everyone can clearly understand them. When they see change communicated in near-real-time, leaders can digest the reasons why they’re happening. Leaders also get the opportunity to do something about it and help out because the changes are small enough that course corrections are still possible. For example, leaders understand when we explain that scope increased because we learned how to capitalize on a new opportunity or when velocity dipped because the team helped out with an unexpected production bug. When we involve leaders every sprint with change, we turn our leaders into partners that journey with us. Change can now be seen as an inevitable piece of building products in unpredictable environments rather than as “someone's fault”. Teams actively avoid the earlier situation where their leaders spend months communicating bogus status to the rest of the organization.
Of course leaders in the negative reinforcing feedback loop above would have difficulty empowering their Scrum team. Would you empower a team that rarely keeps you apprised of the information you need to do your job and when they do, the information you’re given is unreliable and politically slanted? That would simply be unwise leadership.
Imagine you are an agile leader who is asked to shift full decision-making control of your organization's flagship product to a Scrum team. What expectations would you have of that team? You would expect them to be proactively transparent with the state of their product so that you can support them when things change and so that you have accurate information to discuss with your leaders. The 2017 Scrum Guide is clear on Scrum team expectations in this regard:
The total work remaining to reach a goal [is tracked] at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders…[who] collaborate [with the Scrum team] on what to do next.
Trust is defined as the belief that a person will behave consistently with our expectations. It’s a harmful fallacy to believe that to earn our leaders’ trust, the expectations we need to be consistent with is delivering on time and under budget because this is impossible to achieve in a complex adaptive environment. In agile, trust is built through consistently relaying truthful information the moment it becomes available. The degree to which leaders trust their Scrum teams is a function of how reliably they can deliver small pieces of working software, and tell the truth.
A symptom of Scrum teams caught in the negative reinforcing feedback loop above can be overly positive sprint reviews. New features are demoed and celebrated but the Sprint Review lacks any quantitative information on how the team is progressing towards its next goal. If this sounds like your sprint reviews, then you may be actively making it very difficult for your leaders to trust you. Try this instead:
Add an agenda item to your next sprint review to review a burnup chart that details how team velocity and scope changed over the last sprint.
Say, “given our current velocity (averaged over 3 the last sprints) and the scope we know about today, we forecast a likely completion date of <insert date>.”
Be explicit and intentional about your use of the word forecast when discussing Product Goals. While Scrum teams “commit” to focusing on a single product goal, they do not commit to delivering that goal by a specific date.
If getting the information and creating a burnup chart is new for you, be sure to check out my next blog on the topic.
It really is that easy. There’s a reason for the old adage “honesty is the best policy”. With a few simple adjustments to communication style, your team and leaders can succeed with agile together.