Accountability Makes Scrum Work

If you ask a software developer, “What’s the most important thing in Scrum?” He will probably say without too much hesitation something like, “Regular delivery of working code.” That working code is delivered in a ‘ceremony’ called the Sprint Review. Each Sprint (a consistent length of time from 2 to 4 weeks), a team plans what they will do, they do it, and then at the Review they show what they’ve done. They report on their accountability with the working code that they had promised to produce. It’s pretty simple, and wonderfully powerful.

In a non-technical environment, such as a marketing team, the process is still the same: the Scrum plans the work that they will complete during the Sprint, they do it, and at the end, they present the results of their efforts to their sponsor(s) and other stakeholders and interested parties at a review meeting.

The primary difference between a software review and a non-tech review is that in the former the delivery is well defined—some code, but in the latter the material to be reviewed could be a combination of a wide range of things. It could be an analysis of the effectiveness of the promotional budget, a demonstration of improved configuration of a measurement dashboard, a market segmentation report, or the highlights of the preliminary launch plans for a new product. This information typically is delivered in the form of Powerpoint slides.

The non-IT review has other differences. At this review, the scrum doesn’t just review each piece of work (call stories) that they’ve completed as if they were robotically reading off the detailed tasks accomplished by the team members during the previous time period. That would make for a boring meeting that might better be done in the form of an email. They aren’t simply trying to do the non-development version of delivering completed work. We apply the same agile principles differently to fulfill the purpose of this meeting.

At the non-development review, the scrum must do three things:

1. Report on their progress to completing the team’s objectives
2. Present the important stuff from their sprint’s work
3. Ask for anything that they need to be successful

A non-IT scrum sets their priorities based on their well-defined set for a period of time, typically a year. It may be something like “generate $100M in marketing-influenced revenue,” “1000 new names,” “Launch new product line,” or “Redesign the website to communicate new company positioning.” For some objectives, the measurements are obvious, and for other no so much. For each there should be at least one way to quantitatively or qualitatively evaluate the team’s progress toward accomplishment. The first portion of the review meeting should be a concise report on the teams’ progress to their objectives’ respective finish lines.

Accountability on display at Sprint Review Meeting

After reporting on their progress or lack thereof, the sponsors have the proper context to evaluate the scrum’s completed work. The scrum should never attempt to explain how every hour was spent by each of it’s members for the previous weeks. Get to the point. What was the most important stuff that was completed? What did you learn? Here are quick guidelines on what to include in this portion of the meeting:

• Answer any questions that the sponsors had at the previous sprint review that you haven’t already given, and report on any specific requests that they had—if there was an action item identified at the last meeting then them what you did about it right up front.
• Give them the information that they need to know to do their own work better and make good decisions.
• Quickly help them understand the status of your most significant activities. Briefly:
• Tell the bad news as loudly as the good news. They need to know good information to make good strategic decisions.
• Make it as conversational as you possibly can. Ask for their guidance. Encourage probing questions.

Before the meeting concludes your team must ask for anything if needs to be successful. You do not have the option to fail to complete one of your objectives and then say, “Well, we couldn’t do it because we didn’t whatever.” If you need whatever, you must ask for it. Your sponsor will hold you accountable for fulfilling you objectives, and you must hold them accountable for giving you what you need to do so: guidance, budget, help with a political issue, permission to break a company policy, etc.

Accountability is the most powerful of the agile principles and it flows both ways. This meeting is your chance to get the full power out of it. Do not shy away from reporting on your stewardship, and demand the same from your executives. Without a review that emphasizes accountability, the team will not be as ruthless about their prioritization as they need to be in their planning meeting. They won’t be as passionate and successful in their work. They won’t accomplish. The entire Scrum system will devolve from a system of transformative innovation and accelerated accomplishment to just a bunch of meetings that will feel burdensome.

The Sprint Review is the most important scrum event. It brings life to everything else.