Scrum Team Launch
This post is in addition to core Scrum, and is my opinion on how to help boot up Scrum in a company as an Agile business process trainer, consultant, and coach:
What do we need to start Scrumming?
- A single, prioritized, estimated backlog with labeled business value.
- A team passionate to get that backlog done with quality.
To get the backlog in step one, we may need to host a User Story workshop. For the team to estimate the backlog, we may need to collaborate with management, compliance, brand standards and quality folks to agree on an initial shared Definition of Done. For the team to be able to pull from the top of the backlog, the Product Owner and team may need to collaborate on a shared Definition of Ready.
To get the team in step two, we may need to host a visioning workshop then pitch to available people and solicit interest in signing up for the new team. If we have teams, we may need to conduct team tune-ups and coaching workshops, or coach the coach workshops, to have the teams excited to tackle whatever backlog and impediments come up next. Once we have a team, we’ll know it by recording who is on the team in the Team Working Agreement. This poster also states where each of the 5 Scrum activites will happen, and when, along with team Core Working Hours in which all the Scrum activities will be hosted. It also labels who, for now, holds the role of team Scrum Master and team Product Owner. Most importantly, it lets the team record their team name which opens the door for team spirit, a name for a team email alias or other team communications, and team incentive structure.
Once the team is underway, the Scrum Master facilities all 5 of the Scrum ceremonies while pulling positive behaviors from the team. They escalate impediments to the Executive Action Team gathered in the daily Scrum of Scrums, where they also make a daily plan to deliver faster and happier than the day before alongside up to 4 other teams.
The Product Owner works to refine the master backlog that they and up to 4 other PO’s refine and pull from during the Meta Scrum. They invite folks who shape corporate strategy to key Sprint Reviews in order to gather the actual customer product feedback needed to make evidence based decisions for the master backlog content and priority, which is essentially the strategic vision of the company. They invite the customer to refine the team Product Backlog and Master Backlog during sprint review.
According to my emerging theory of coaching, The Enterprise Agile Coach, a role assigned to each group of 5 Scrum Masters, has an important additional responsibility during an agile transformation: making it visible. Here’s how I like to see it when working with embedded coaches:
- Per team, record if in that sprint the team had all 3 Scrum Roles during the sprint and then if each of the 3 roles is delivering the output required of that role, and receiving the input required of that role. An expert Enterprise Agile Coach may be able to assess this while spending less than 5 minutes with a given team.
- Per team, record if in that sprint the team held all 5 Scrum Events during the sprint and if each of the 5 events is delivering the output required of that event, and receiving the event required of that role.
- Per team, record if the team is making their work visible. A recommended starter set that should be current each day and visible to both the team and leadership in the area they each do their work:
- Scrum Board, showing the prioritized, estimated, and labeled business value Product Backlog and Sprint Backlog. Triple Bonus Points in my opinion if the Sprint Backlog then flows through columns representing a current-this-week value stream map of the team’s breadth of delivery. This last one is a clear sign of an expert and transcending Scrum Master on that team, in my book.
- Sprint burn down chart and release burn down chart.
- Potentially Shippable Product Increment. If this isn’t immediately visible in the Scrum Room and to management, on the daily, it’s a red flag stop the line investigation as to why. Likely the team does not have a clear Definition of Done, or has an impediment to meeting the current DoD.
- +/delta retrospective on the Agile Manifesto.
- Agile Metrics.
- Team Velocity for each sprint.
- Acceleration recorded from sprint to sprint. If this is accelerating sprint to sprint and NPV/point isn’t going down, we likely have a ROCKSTAR Scrum Master.
- List of each retrospective’s Try, which is also called the Kaizen, with acceptance criteria, and if the Scrum team accepted the Kaizen as completed during sprint review or rejected it as not done (the PO has final say, but on the Kaizen card the PO usually asks the team if it happened, as it’s their process improvement and they are the customer).
- Quality metric per sprint. This varies per industry, from Defects Found in Field to Open Bugs to Customer Support Calls or injury reports. If this is improving sprint to sprint, we likely have a ROCKSTAR development team.
- Time to fix a defect per sprint, from the time it was found until the time it was resolved.
- NPV per point per sprint. If this is being tracked, and if it is going up, we likely have a ROCKSTAR Product Owner on this team.