I've been supporting some people who are relatively new to the Scrum Master role recently. There are moments where my favourite part of my role is talking to people who are right at the beginning of their journey. I love that I get the chance to shape how these people think and interact with agile, and I also get a sense of just how far I have come from those first days of moving away from software development. (And it’s a good job too, as I cannot remember how to code anymore.)
A question I’ve repeatedly had, not only recently but throughout my career, is how do I change my dataset to make any given chart the way it should? Of course, it’s never framed in this way. The most recent anecdote that a Scrum Master brought to me was this:
My team’s velocity shows that many story points roll over each sprint because before we deploy, we wait for the business to review the work. Sometimes the business stakeholders take a couple of sprints to review the work. They don’t always review all the work at the same either. Our velocity is irregular and out of our control. How can I change the way Jira reports velocity so that it doesn’t include the time it takes the business to do its part?
My response was:
These charts are here to show you where there are problems in the process. The story you’ve told me about this chart is what you should say to the business stakeholders involved. Explain to them that you could deliver more quickly if they could be timelier and regularly review the work before deployment. Discuss these charts and ask your stakeholders how they could help resolve the problems you see in the data. For all the charts you’re generating, look for the issues in the process to fix rather than manipulating the data so that it looks good.
I have been through many different flavours of agile training, and it occurs to me that perhaps we’re not clear enough when we talk about using data and charts in these frameworks. In training I’ve attended, I’ve seen the trainers explain what a good chart looks like and what a bad chart looks like, but I don’t think I’ve ever seen a trainer explain that the bad graphs are pointing towards dysfunctions that we need to solve. Could this be a reason why I’m often asked how to fix the data to make the chart look like it should?
I don’t think in any of the courses I’ve been on (outside of the coaching-focused ones) have I heard a trainer talk about building resilience in a team. When we’re first moving towards agile, we see many behaviours that we consider dysfunctional and try to fix them. Perhaps a better approach would be to help the people involved build resilience against these dysfunctions and allow them to find the solutions they need for themselves. In this case, teaching people that the data are there to help them have hard conversations more dispassionately.
Ah, it is the old "change the data to make it look pretty" approach. :) You are very right about training. This is what your burn up/down looks like ... in a perfect world. You have to listen to what the data is telling you. That analytical step is definitely missing or glossed over. In your example, could the team create a sprint(s) dedicated to the business reviewing the work? I'm thinking more SAFe I think. Sprint, sprint, sprint, review sprint, release?