LF Tips to Effectively Coach Outcome over Output to Leadership
There are two different perspectives floating around the office, one valuing Outcomes (Teams) and the other valuing Output (Leadership). The status quo here has been to capture this one specific Sprint metric as Commit/Complete percentages and trend them sprint by sprint, among several others.
If that result looks like 75% for example, then it's become expected to provide a blurb explaining the result. I don't like the idea that we have to make excuses for anything less than 90%, because our purpose isn't to stay busy and have everything finished 'on time' and create perfect plans, but I do want to support Transparency!
The Scrum Team doesn't much care about these metrics either because they don't tell the story that reflects the success of the team. It only speaks towards effectiveness of creating a perfect plan, which isn't their goal. I feel like I've done a great job coaching the team to be motivated by success in this way.
Leadership isn't looking at the functionality but rather just ensuring we're going to be 'on time', which makes sense as to why they want to monitor output because they aren't the customers of the Team increment. If they see a Sprint finish at 75%, they would assume we're falling behind, which definitely isn't the case.
Not all items in the Sprint Backlog relate to the Sprint Goal. You could say it's about 70% Sprint Goal and 30% everything else. We have additional responsibilities like:
- Service Desk support for existing functionality
- Occasional Sprint 0 activities like research/design
- Supporting other teams
- We aren't the only product team and some projects have dependency work that we each support.
- Sometimes we include work we just want to get started for the next Sprint Goal, rather than insert a smaller less important story.
So far we've tried reducing Commit/Complete % scope to just Sprint Goal related work. However, as we do the work and learn things, the Sprint Backlog will change. This is all desired Scrum behavior, but Leadership views it as inconsistency and unpredictability...whereas the Team mentality is to consistently and predictably deliver increments which meet functional expectations.
How then can I bridge the gap and get Leadership to trust the Scrum Team outcomes instead of supporting the metrics that allow them to 'manage' an interpretation of success?
Hello John,
To me, it appears that the management is over-dependent on the metrics which itself might not be right or sufficient. Commit to Complete ratio is frequently used as a productivity metric in other industries as well and often used to reprimand the slackers (such organizations are generally not successful). Is this metric used in the organization for the same purpose?
If that result looks like 75% for example, then it's become expected to provide a blurb explaining the result. I don't like the idea that we have to make excuses for anything less than 90%, because our purpose isn't to stay busy and have everything finished 'on time' and create perfect plans, but I do want to support Transparency!
This suggests that a numerical value is used as a benchmark that is clearly not reflecting your teams' real value creation. Does the team also view it as an incompetent/ insufficient/ inaccurate reflection of their work?
One way you can deal with it if you feel that it is absolutely mandatory for SM to provide such a metric is to add an additional value point which can be either no. of increment delivered/ tasks completed/ requests completed/ time to respond etc. This may aid in real transparency and may change their definition of success or allow them to "manage" interpretation of success. It may also help them to grasp the
Eliminating numerical quotas for the workforce and numerical goals for management is essential to have a truly agile mindset. In my opinion, your team is demonstrating that agile mindset by ignoring something that does not work. It would be a nice idea to explore which other metrics are helpful for transparency and which are being used as a numerical quota.
Yes the team does view it that way. They go along with reporting the numbers as they are but put little stock into them, unless of course they wanted to compare a change they make to Sprint Planning is effective in some way, but that's pretty rare.
You know, I never considered it a "quota" but that's exactly how it's being treated. Thank you for that perspective. That gives me something to research.
There are two different perspectives floating around the office, one valuing Outcomes (Teams) and the other valuing Output (Leadership)
...
How then can I bridge the gap and get Leadership to trust the Scrum Team outcomes instead of supporting the metrics that allow them to 'manage' an interpretation of success?
Why does leadership value output over outcomes in the first place?