Working at a startup usually requires a keen eye on the future. Keeping an eye on the road to success, knowing which milestones to check off is necessary. But that requires experience. It is quite possible for any group of motivated people to make a mistake but the real challenge comes in not repeating it. And that is where the agile concept of retrospectives come in.
A retrospective, as the name suggests, simply is a look at the immediate past in order to evaluate whether the basis on which the recent decisions were made, were sound or not. This helps in fine tuning our analytical abilities and also helps us weed out any red herrings that may have crept into our process.
There are many recommended ways of doing retrospectives. You can either start with the team simply stating out what went wrong, what went well and what was not obvious over the course of the last iteration or sprint and then discuss the ones that the team marks as most relevant. This is a quick and simple way of getting started and usually ends up with a few action items towards the end. This retrospective style has one flaw though - it is not very good at showing trends of the process.
The one style of retrospective I really like is the timeline retrospective. This sort of retrospective allows you to see the entire process plan of the last iteration, the decisions that evolved from that and the effect of those decisions. This works as follows:
You draw a timeline of the last iteration, broken into equal time chunks. For example you may have a 2 week long iteration, in which it is quite feasible to do a timeline retro every 2 to 3 iterations to provide a better scale of view. You break the timeline into week long chunks.
Instead of just putting up the good/bad/huh cards up on the wall and grouping them based on context, you place them on the relevant place in the timeline. This allows us to see whether any particular type of issues, good or bad emerged at one point in time or whether they were distributed.
Instead of how in the classic retrospective, whereby you group the cards then together on the context, there is no grouping in this one. This is because you want to see how the decisions made over the course of the iterations affected the people involved. This also shows you whether a person was more affected than others or vice versa.
The discussion that emerges from this retro should focus on the following:
Is there a trend between a decision and the affect it had?
Is there a trend between the the team feeling good/bad over any particular period of time?
Is there a trend between people involved and whether something was not communicated?
This particular retrospective style is highly effective at not just demonstrating how things went well in the last iteration(s), but also if any trends are emerging.
All in all, I highly recommend it.
Head of DevOps at Fillr.com