Scrum Mastering the Backbone Team

I joined Autodesk/Shotgun’s Backbone team as Scrum Master in July 2018—a team formed with the express purpose of building and improving the mission-critical microservices that comprise Shotgun Software. Things like:

  • Shotgun Permissions framework

  • Database Performance & Query optimizations

  • Transcoding and Virus Scanning

  • Direct file upload to AWS (for both web uploads and API endpoints)

 

  • Data model modifications for Desktop software integrations

  • Creation of Python and REST API endpoints (used 2+ billion times/month by our customers)

  • Creation of a new multi-tenant event service to handle email notifications and outbound Webhooks

Improvements during my tenure as Scrum Master

better team processes

I instituted a number of common sense changes to the way the team worked, mostly to reduce distractions and increase velocity, but also to increase our bus factor. Below are some of my favorites:

  • Created a “dailies dashboard” that became the tactical focal point of standups:

    • Hot topics (escalations, regressions, 911’s, etc.)

    • Next 6 weeks of code freeze deadlines

    • Vacation and time off schedule to keep tabs on any dips in team capacity

    • Sprint Burndown chart

    • Rolling team velocity chart

    • Sprint board of all tickets left to do

  • Phased out some bad habits such as:

    • Adding tickets to the sprint without team discussion

    • Adding escalated work to the sprint without bumping out scheduled work

    • Under-estimating tickets without fully thinking out all of the documentation consequences

    • Doing unticketed work that bounced in from other teams in the form of innocuous sounding requests over Slack or email

  • Phased in some new practices such as:

    • Creating tickets for investigations and technical spikes

    • Regular Sprint retrospectives, video recorded over Zoom, then linked from the retrospective wiki page

    • Weekly client-driven backlog grooming meetings in coordination with customer support stakeholders

    • Writing incident reports for regressions and serious software bugs (patterned after devops) so that regressions would be understood, analyzed, and reported out to all the engineering teams at Scrum of Scrums

    • Pair testing with developers, with documentation as an end-goal deliverable

unfinished work decreased

By “unfinished work”, I am talking about tickets that were assigned and added to a specific sprint, but not closed out during that sprint.

Before: 863%

In the 5 sprints prior to me joining the team as Scrum Master, sprints were over-committed by 863%. The team was committing to more than 8.5 x the work it was delivering.

After: 133%

In my first 5 sprints, the average discrepancy between what we were commiting to and what we were delivering fell to within 33% of eachother.

Average Developer Productivity went up

By “developer productivity”, I am talking about the total number of story points associated with all closed tickets, broken out by assignee.

Before: 5.4 pts/DEV

In the 5 sprints prior to me joining the team as Scrum Master, the average story points completed per developer per sprint was 5.4.

I did some analysis of the velocity of my former team, and found that their avg. points/dev was around 8-10. Because the two teams do similar work, I surmised that the first team’s story point average was probably a reasonable target goal for my new team.

After: 9.47 PTS/DEV

In my first 5 sprints, average story points completed per developer per sprint went up by 75% to 9.47.