Retrospective Updates
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.
The agile approach to improvement is based on frequent retrospectives, ideally every iteration. See The Agile Samurai, section 10.5. A common technique in retrospectives is a start-stop-continue review, but this can lead to blaming and long lists of things to change with little follow-up. The key is to focus on experiments.
- The team makes a concrete simple change in how it does things or how it measures things
- The goal is to improve metric that matters
At least a day before each weekly coaching meeting, either as part of a swarm or separately, the team
- reviews their metrics for product and team development and how previous process changes are doing
- proposes, discusses, and decides on a new change in process and/or metrics
- updates their dashboard with the appropriate details
- updates the retrospective summary sheet
The retrospective summary sheet for each team is in the Team Data spreadsheet. Link on Canvas. The summary sheet looks something like this:
Each week the team adds a new summary row above the previous entry, no later than the day before we meet, so that I have time to read and prepare comments before we meet.
In the coaching meeting, one team member will answer questions about what's been written and another will take notes. These two roles rotate through the team every week. Decide and enter who is doing what before we meet.
A large team that is split into two coaching meetings should still have one retrospective, but enter two update rows, so that names and notes can be kept separate for the two meetings.
Dashboards
Dashboards are an experiment for this quarter. During coaching, we will look at the team's dashboard document for details that clarify the retrospective summary.
A near-empty starter dashboard document has been created in the team folders on the shared Google Drive. Each team should expand and format that document to suit their needs. How is up to the team. I expect to see some creative ideas.
A dashboard needs to provide a quick at-a-glance picture of the metrics the team is using to track their health, and a description of the team's current working processes. The health metrics should briefly and clearly indicate the value for each metric and if it has recently gone up, down, or remain unchanged. More details should be available later in the dashboard or in links.
A dashboard needs to be very low effort to update. You should be able review and update it as part of your pre-coaching retrospective review. It should help you, not slow you down. If there's friction, fix it. Look for ways to avoid duplicate data entry.
The key things to see in a dashboard are the metrics your team is currently watching and the process changes the team is experimenting with. The metrics should summarize in a useful way trends the team is tracking in more detailed information, such as your mood charts, your gitstats, your messaging channels, your backlog tasks, and so on.
The process description should summarize how the team works. How are swarm meetings structured? How are tasks defined, prioritized, and allocated? Where is the backlog kept? When are branches created? When deleted? This will become more detailed as I ask you questions about how you do things, such as when do you rotate, do you use a timer, when and how do swarm subgroups contact each other, etc. Here are a few examples of process descriptions for teams that have reflected and tested many ideas over time. Your processes will be less detailed and well-formed because you're just starting.
How to Write Good Reports
Be brief. Less is more. Put details in the dashboard. The point of the summary is to see at a glance how things are doing compared to the week before.
Start with a summary like "X was better/worse/about the same" followed by data to back up the claim. E.g., "Velocity was a little better. 10 story points done compared to 8 last week."
Finding good metrics takes serious thought. Agile goes for simple. Mood charts have just three options. Story sizes are just 1, 2, 3, 5, 8, and big. (Many in Agile think even those numbers are misleadingly specific.) Story priorities are just rank order. When summarizing, don't try to average such things. Look for useful counts, like "number of yellows in a swarm", "most yellows from one team member in past two iterations", "number of people with no commits in last iteration", and so on.
Avoid anti-agile process changes. A change is anti-agile is if it takes a lot of work to do or introduces a delay in getting code tested and deployed. An example of change with both problems is "all code changes must be documented in Slack and approved". A change is anti-agile if it reduces learning or increases risk, such as "assign tasks to the strongest developers".