The rewards of coaching
Recently I’ve started working with one of our Project Managers who is working towards obtaining her Professional Scrum Master (PSM1) certification. We have a fortnightly catch up (which we had this week) where we run through different aspects of Scrum and how it relates to the reality she is experiencing with the teams she is working with.
What’s been great from my side has been the conversations we’ve been having have not been centered on ‘passing the exam’, they’ve been on checking her understanding of the framework and then how reality differs from that.
As well as that, it’s really enjoyable to hear her identify where potential improvements/changes could be made to her current context and to ask questions about an idea around an approach, as that shows the learning is landing. It’s these types of discussions where I feel the most satisfaction from a coaching perspective , as you can see how the individual you are working with is understanding and growing their own curiosity, in particular through practical application of the newly acquired knowledge.
If she’s reading this, a thank you to her for making the past few weeks really enjoyable from a work perspective.
Scrum
This week I talked to a fellow coach for one of our vendors about concerns I had in the way a particular team was practicing Scrum. There were a number of things observable just from a quick browse of the team area/board that stood out to me as being anti-patterns or just bad practices being inflicted on a team new to their Agile journey. It still amazes me over the years how people still persist with techniques that are quite outdated/never actually within the Scrum Guide. Now, I will fully admit that in my own Agile journey I was once the same in that I used to believe commitment to x number of backlog items, story points and velocity were of paramount importance, however after reading/learning more and experimenting, I’ve got my own list on what modern day Scrum looks like. That list includes (assuming you’re nailing your events and sticking to scrum values):
Tasks are optional
Anti-pattern — tasks in hours, or for that matter any individual measurement of hours per tasks
Anti-pattern — Reporting on a per individual basis — names on a dashboard are a no-no
Kanban boards are a must, and should reflect the end to end flow of value (i.e. they don’t stop at “UAT”, Done = Live)
WIP limits are a must
Sprint goals are short and ideally measureable; anti-patterns are long and ambiguous sprint goals
Story points are optional for the team only, should not be used for any forecasting/predicting (Average velocity must die)
Prediction on dates/scope should use monte carlo simulation or have an attributed percentage likelihood of outcome (which we know will change)
Continuous everything — refinement, exploration, compliance, testing, integration & delivery
Other sensible metrics to use would be:
- Work item age, cycle/lead time, net flow, throughput, lead time for change, deployment frequency, change failure rate, time to restore service, team health check, no. of experiments
Source: 4 Key Flow Metrics and how to use them in Scrum’s events by Yuval Yeret
Those of you who will have studied and/or taken the Scrum with Kanban course will notice the vast majority of my thoughts are the same as what is echoed in that material. For our teams practicing Scrum, this is what I’d expect them to work towards…ideally without being ‘forced’ through the old training wheels of story points, velocity, hours breakdown etc.
Product Metrics
One thing I’ve always found difficult are product metrics for internal developed products.
Doc Norton has recently updated the final version of his ‘Escape Velocity’ book which I re-read this week. The book has an excellent chapter on what good product/outcome metrics you could potentially use that are much more meaningful than velocity.
Based on what I’ve read, as we transition more teams from project -> product, key metrics for our teams are going to be:
- Feature usage
- Adoption Rate
- Growth rate
- Relative Feature Adoption Rate
- Retention Rate
Next week
Next week we’re running a two-day DevOps People & Process workshop with Microsoft, which should be really interesting. As a team we were a bit taken aback by the overwhelming response for people who wanted to go, so I thought it better to give up my spot on the session for someone else.
I’m also heading to an event on Thursday which is hosted by IDC and Slack on A Framework for Agile Collaboration — should be some interesting discussion around the organisational culture and change.