Weeknotes #15
Metrics and Curiosity
This week I spent a few days (along with some big help from my colleague Tim) reworking one of troy.magennis amazing team dashboards from Excel into Google Sheets.
I view Troy’s work as really important to what we do in our industry, and the fact he gives it all away for free in a format that is easily consumable with clear instructions is even better. He has been one of my biggest inspirations in the last few years, always available to chat, give feedback and share ideas with. If you are going to Agile 2019 this year, be sure to check out the Data & Metrics track he has put together (I’m biased as I helped review the submissions!).
On the topic of metrics, it’s great how beneficial they are in unearthing information that isn’t immediately visible to a Coach/Scrum Master/Delivery Manager. A great example of that was this week with someone I’m coaching, where we looked at a scatter plot for her team:
Now, whilst this is great in showing you how long things in general take (85th percentile — 16 days — not bad as this team are doing two week sprints), it should, if it’s an effective chart, spark curiosity and questions.
Good coaches then find a way to safely introduce this information to the team (See: Goodhart’s Law) and leverage it to have better conversations as a team.
If we go back to the original visual, these are the sort of things I would be considering:
That way we’re asking open questions centered on improvement, rather than making the team feel they are being critiqued for performance using data.
Estimation
Estimation is always an interesting topic in the Agile world, from story points, t-shirt sizes, fibonacci or fibonacci-esque, cost of delay or even #noestimates there is always passionate discussion in this area. This week task estimation came up, specifically the topic of needing to estimate in hours for tasks, with some of our coaches working with teams saying that they ‘needed’ the team to estimate tasks in hours to understand capacity. Now I’ll admit this was a practice I once encouraged at the beginning of my career, however having learned and experimented with other techniques I can see it’s not effective, and something I wouldn’t get teams to start with now. The days of telling (or as I witness from some other Scrum Masters — yelling 😐) a team member to change their hours remaining in the digital tool from 3 to 2 are ones I look back on and cringe at. I was trying to explain to the coaches that it’s a bad practice, hourly estimation is nigh on impossible and that we should focus on flow, small stories and limiting WIP.
Don’t believe me? Sutherland himself says:
So as practitioners who are all about empiricism, why push old/bad practices on teams and ignore the empiricism that shows they don’t work?
Focus on flow, manage WIP, and slicing work into small vertical slices will tackle your capacity issue in a much more effective manner than updating your hours in any respective digital tool will.
A framework for Agile collaboration
On Thursday night I went along to an executive dinner at the Connaught Hotel hosted by IDC & Slack.
It was a really interesting evening, with approx 30–40 people from different organisations big and small sharing about their own Agile journey, challenges they were facing and success stories. Common themes over the dinner around approaches that help to success were, leadership buy in is a must for success, trust, measure outcomes over outputs and the shift from project -> product. The two challenges I heard most frequently used were culture and the funding model, which I would agree with.
A member of a large bank on our table in particular stressed the importance of having HR as part of the change which, given what I mentioned earlier, helped me validate we were making the right steps forward.
Some surprising points for me were around technical practices, in particular on our table where some people didn’t think they were key (albeit important) to organisational agility. When you consider the work from DORA and Accelerate, which both talk about how technical practices directly influence organisational performance, I found that odd. Another interesting observation was around the love digital tools (Jira, Azure DevOps, Trello etc) were getting from everyone.
One table in particular began their answer to the main topic discussion point with “tools and process”. This was confusing to me given the values in the manifesto. In summary, I don’t think there was anything massively * new * I learnt over the evening, other than big organisations have similar issues to ours. It confirmed to me certainly that our current approach is sound and, whilst it may take years to get there we are getting there incrementally.
Next Week
Next week I’ve got some conversations around release management, which should be interesting given the inroads Jon made this week in automating ticket creation/closing for deployments with SNow and Azure DevOps.
I’ll also be heading up to our Manchester office, running another 1-day Agile Foundations session for a number of new joiners in our IT organisation.
