A Retrospective

One of my first experiences as a team coach was to help the developers work with a stakeholder they found difficult because the stakeholder would constantly shift priorities and demand “more” to be delivered. There was a specific demand for all tasks to have estimates in days and hours with a concrete delivery date for the project. The team and I had generally talked about the fuzziness and unreliability of specific date estimates and we had pushed back, albeit unsuccessfully.  The stakeholder wanted a date to go tell their customers, and that was the end of it, as far as they were concerned.

One day the stakeholder came to me and asked for the next delivery date. I felt a need to protect the team and assumed they did not want to have yet another conversation about estimating projects, so without involving the team, I took a look at where the project was and what steps were left. I reviewed our empirical data to find out how long those steps took in the past, and gave a date: November 3rd.

And I turned out to be right, it was delivered on November 3rd.

Well, no, I wasn’t “right”. I was wrong not to involve the developers, who did not know I had given a date on their behalf. Though the developers would not have faced direct consequences, it would have added to the stakeholder’s frustration if they had missed the delivery date. There was always the possibility for an unpleasant outcome, and I just got lucky gambling on my empirical guess.

I was wrong to give the stakeholder a concrete date, even if my only alternate option was to have yet another difficult conversation about how hard it was to give definitive estimates.

And I was wrong that the date ended up being the real delivery date, because it gave the stakeholder the wrong idea that we could estimate reliably. They would now want to have the same degree of certainty with all future estimates.

What should I have done?

In retrospect, I would not have given a date. I would have had the difficult conversation, one more time.

Up to that point, we had only talked about benefits for the developers. This time, I would have framed the conversation around how to benefit the stakeholder. I would help them give the team an idea of all the critical things that ran through the backlog, and not just hear about it project by project. This would allow the team and stakeholder to collaborate on how best to organize the work. I would also involve everyone in a conversation about how to limit work-in-progress(WIP) and encourage flow as well as demonstrate how it would benefit the entire organization. I would have moved the conversation past a simple, “dates are hard”, and towards a collaboration about what we can do to enable frequent delivery.

The role of Scrum Master is to empower the team to become a self-managing team. And true empowerment comes from confidence in your ability to manage any situation. By shielding the team from having a difficult conversation with their stakeholders, I believe I got in the way. By helping to guide the discussion between the stakeholders and the team, a coach can help them collaborate on solutions that acknowledge uncertainty.

Finally, trust is hard to earn, and easy to lose, so we must examine situations thoroughly to avoid acting too quickly and making a mistake.