Daily Tally

Have you attended (or participated) in this daily stand-up meeting?

Q. What did I do yesterday?
A. I worked on (pointing) this card yesterday. 

Q. What am I doing today?
A. I'll continue working on this card today. 

Q. What's in my way?
A. Nothing is in my way.

If this continues for an entire iteration the team looses credibility and trust with themselves and other stakeholders and teams. One technique my teams use to provide visibility to potential risks is a "Daily Tally" on every user story/defect card.

5 Point User Story Card with Daily Tallies
Black - Developers
Orange - Testers
Red & Highlighter - Back Flow

Every day we place a tally mark on the card. Developers and testers have unique color markers and we tally from the the left to the right of the card to represent a timeline. The colors tell us how long we've been working on a card and how the time has been split between the developers and testers.

We also add a red tally when a card is returned to the developers from the testers. A red tally indicates that we missed an acceptance test scenario or introduced a defect.

The team uses the information from the daily tally in two primary ways:

1. Retrospective Item - A red tally mark shows when we have an opportunity to improve by reviewing the causes for the back flow and determine if we want to prevent it in the future.
2. Pushing help - When the number of tally marks equal the card's point estimate it triggers the team  to ask "How can we help?". This is not a failure of an individual or the team. It is a mechanism that makes the team aware to potential risks as early as possible.

We still use more traditional tracking methods, but we've found this technique effective for spotting trouble early and providing examples (with data) for retrospective meetings.

Are all your changes included in the next release?

I'd like to share one technique I've used with teams to help error-proof their branching to verify the next release will include all their changes. This technique only applies to the "One Branch" strategy since a single code line will always contain all the changes.

Error-proof Branching Strategies

• One Branch (2 code lines) - main (of default) and release (or stable)
• No Branches (1 code line) - main (or default)

The main error that occurs with branches is that developers forget to apply their changes to all branches. For example, a hot fix needs to be made to the release code line and the development code line to makes it in the next release. Like most errors, the developers aren't malicious and telling them to "do a better job next time" won't improve their behavior.

One highly effective technique I use with teams is to run a script once a day to validate that all changes made to a release branch have been applied to the main (or default) code line. Since this happens daily, any merge conflicts are minimized.

In this example using Mercurial, this batch script is called from a Jenkins job that runs once a day. If a commit exists on the release branch that hasn't been merged to the default branch it will fail the build. I hope you find it useful.

Branching Strategies

I've stumbled across many creative and interesting branching strategies during my career. I'm going to categorize the branching strategies in to two categories: Error-prone and Error-proof.

Error-prone Branching Strategies

• Branch per release per environment based on previous release
• Branch per release
• Branch from a previous release
• Branch per environment

Error-proof Branching Strategies

• One Branch (2 code lines) - main (of default) and release (or stable)
• No Branches (1 code line) - main (or default)