April 5 Day One -- What each team needs to prepare for the first day of class!


TTh 11am - 12:20am


Tech M345


Chris Riesbeck


Retrospective Reports

Continuous improvement is an essential aspect of agile development. It doesn't happen automatically. It involves each team, no matter how smoothly things are running, taking time every week to identify the most important area for improvement, discussing and making some change, and tracking what happens to see if the change helped or hurt.

In agile, the meeting or portion of a meeting to do this is called a retrospective (The Agile Samurai, section 10.5). Retrospectives can be hard to do well.

Agile retrospectives are a good way to test how well you, as an individual understand and can apply agile thinking (values, principles, common practices) to real team and product development problems. Agile thinking means

Therefore, every week, every team member will submit a new retrospective, as described below. I will enter comments and scores before the meeting, if possible. These reports will be part of our coaching meetings.

Scores are from 0 (no entry) to 5 (really impressive insight). Expect terrible scores early on, be happy if you get a 4, post on Facebook if you get a 5. Your top 4 retrospective scores at the end of the quarter will be added to your team score.

You may think AngularJS coding or configuring push notifications is hard, but I have seen all students struggle far more with retrospective analysis than anything else. It's a form of critical reasoning that requires frank self-assessment and clear evidence-based analysis.

Retrospective Report Process

There are two parts to the retrospective reports:

Team Cause-Effect Diagrams

Critical to useful retrospection and improvement is understanding what's going on. If your team keeps releasing buggy code, saying "be more careful" is useless.

There's a really nice description of how to do a good causal anaysis here (PDF).

Every team will create and maintain a team cause-effect diagrams in the Google Slides file in their respective Retrospectives folder on Google.

The team decides when to generate a new diagram slide. You should create a new diagram when you:

When making a new diagram, feel free copy from a previous one.

No individual diagrams. The team needs to agree on the causal analysis. If some people don't think X is causing Y, then evidence needs to be gathered and reported on. The team does not need to agree what problem to attack first, of what solution to try. That discussion can happen in coaching.

The Retrospective Spreadsheet

To structure your reports, we use the 394 Retrospective Workbook.

Every team has their own workbook in their Retrospectives folder on Google. Each workbook has a sheet for each week's report. Each sheet has a column for each member.

Once you choose a column, use the same one every week.

The focus is on "given this causal analysis, here's a simple agile-friendly relevant change to try."

In the causal diagram row, put in a clickable link to the specific slide with the diagram you're talking about.

In the change row, specify which of the changes in the diagram you're talking about.

In the issue row, specify which of the metrics that matter you're focusing on. Don't repeat the causal analysis in the spreadsheet. Focus on a proposed change, e.g., "move the meeting", what that change might affect and why, how you would measure, and why the change is "agile-friendly."

Many process changes look good on paper but have very bad results, and are definitely not agile-friendly

Filling in the retrospective spreadsheet


A few ground rules:

Some advice:

An Example Analysis

People are late for meetings.

Attendance is the number one issue most teams raise in classes with team projects. And probably the most common fix I see teams propose is some kind of "shaming" for lateness, e.g., keeping a lateness board, making late-comers buy pizza, making late-comers where a "late" hat, etc.

The most important thing to realize is punctuality / attendance is not a problem in and of itself.

Not doing a process is not a problem. Problems are failures to achieve goals. A process per se should never be a goal.

Imagine a team whose members were always late to meetings, but that produced high quality code week after week and enjoyed doing it. What effect do you think those proposed process changes will have on such a team.

Further analysis is required.