Timeline

The timeline retrospective technique is an agile tool to look back over a specific period of time and capture key data points and information to help drive forward positive changes. These data points normally relate to specific events/challenges (such as a project kick-off or a budget cut after a quarterly review or a power cut that took all the production servers offline) but also can surface regular patterns of behavior, communication break-down, bad planning, and inefficient processes.

As you will be looking back over a period of time and surfacing details of things that happened (or didn't as the case may be), it's always a good idea to narrow down what you will be examining. From experience, you should consider a specific large and complex project or a business initiative or a specific release—I'm sure you'll also have some other ideas. As you are trying to expose problems and issues within your delivery process, I would not recommend picking something that went swimmingly well at this stage as you might not learn as much as you could—that can come later down the line to ensure any changes made have had a positive impact. Whatever you pick should be the focus for the workshop(s).

The format of a timeline retrospective is quite simple:

• You define and agree the timeline (that is, start date—end date) and draw that horizontally along a wide wall (or rather on the paper covering the wall).
• You then break this down into smaller periods of time (that is, months or weeks) and mark those points along the timeline.
• Next, you get all participants to write out sticky notes related to notable events that they remember during the period in question and ask them to add these to the timeline on the wall (if you have remote members taking part ask someone within the room to act as proxy for them). There is no limit to the number of notes—encourage participants to keep going as long as possible.
• As this goes on you will start to see groups of similar event notes forming—you should encourage the participants to start grouping these together. Some of these specific event notes may occur more than once throughout the timeline indicating a pervasive problem.
• If there are no more event notes to add you should then instruct the group to mark the notes with colors (either stickers or with a marker) indicating how they feel about the event—green for glad, blue for sad, or red for mad.

Throughout these, you should be actively encouraging open and honest discussion throughout the participants—maybe picking on specific event notes and asking questions such as "Is there any more detail to add?" or "Did anyone else notice this?" or "Did this happen more than once?"

You will now have a highly visual representation of what events happened over the timeline and how these events made people feel. You can then facilitate an open and honest group discussion applying some focus on those events that provoked the most emotions. During this discussion, some solutions may be put forward to resolve the pains—these should be noted for later use but hold off agreeing on an action plan for the moment.

The following depicts an example output from a timeline workshop representing a rather painful project and should give you some ideas of what you should end up with:

Another proven and well-documented technique is value stream mapping.