Star Trek… I’m afraid this post will give away my age but I’ll say it anyway; although I would not consider myself a “trekkie”, a startup is in many ways like a Star Trek season series. An episode starts with a happy bunch, travelling and exploring planets and space. Suddenly something unthinkable happens. Something that nobody could expect.
Could things turn out better for the Enterprise crew if they spent some time discussing after the end of each episode? How about a nice retrospective on what went well, what could have been better and what could be improved? Until the next episode of course… and J.J. Abrams forbid…
Communication in a small team may sound easy but in reality often remain things that are not spoken. It is part of human nature. It could be something that I for example didn’t share because “This is how it should be”, “Everybody knows that”, I “didn’t have time” or because we, as a group, choose to pretend that “nothing ever happened”.
– Sounds familiar, right?
In a team working with Agile there are tools available that may prevent a catastrophe. For some time now my team and I do this. In a nutshell, for every sprint we do the following Scrum meetings:
– Daily sync meeting (Daily standup)
– Sprint Planning
– Demo session
– Backlog Grooming sessions
Out of all these important “meetings” or “events” I consider retrospective as the most fundamental. I believe there is something cathartic about looking into oneself. Same goes with teams. We are able to see and discuss things that usually stay “under the radar”. Bring them on surface and feel better afterwards.
We have noticed that our Retrospective meeting is better when it is not structured. We do have a rough plan of what we want to discuss though. Time is the only thing we are firm about. 1 hour strictly! That’s all!
We start by summarizing the previous retrospective and sprint and review everything we had signed as important. Then we spent a brief moment bringing up any major or unexpected things considering our last sprint. If necessary we can get back to them in detail later on.
1. “The needs of the many outweigh the needs of the few, or the one”.
Here’s what we found out helpful in our meetings: We all take 5-10 minutes to think silently and write down the things we:
a) Did well and should continue
b) Could do better by introducing minor modifications
c) Should improve by introducing a major change. This could include things we should stop doing as well.
Now let’s make it more personal. The problem with discussions of this kind is that they may sometimes feel like criticism. Especially if they involve negative comments about something that can reflect badly to the team member responsible. He may feel the need to defend his work and that could block the communication altogether! There is therefore a fine line not to be crossed. Everyone has the right to say his opinion, right or wrong. But retrospective is not a meeting to start arguing. It is an introspection of ourselves. Hearing what the other has to say may provide a clue about possible miscommunications or alternative course of actions.
2. “Vulcans never bluff”.
After this silent brainstorming session, we take turns and stand up. We each talk about the things we identified and stick a Post-it on the wall. As I already suggested, we may not all agree on the things pointed out so far. For this reason no-one interrupts the person talking. After we all finish, we have a wall full of Post-its and a clear view. Do not worry, by now the hard part is already over!
Next, we choose what to do for the following sprint. We stand up again, approach the wall and “play” with the Post-its. We each select what we consider most important and, one by one, we place it on top. We may sometimes need to merge some of these Post-its. An important part of this process is voting. We use Hernik Kniberg’s three dot voting system. Everybody votes on the improvements that need to be introduced for the next sprint but can use three votes on one improvement only.
3. “Insufficient facts always invite danger”.
One of the things that are still elusive are estimates. Estimating is not easy, but it comes with experience. The problem of estimating a story, not only resides to the actual user story duration or size. There are external factors in a life of a startup that can kill your estimate. For this reason you have to take into account your actual velocity. According to Henrik Kniberg, seeing and comparing these two numbers is important. If there is a big difference, we try to analyze why.
4. “Change is the essential process of all existence.”
We keep everything on the wall on purpose. This way we all have a view of the changes we need to put in place. There is a chance that some of the improvements proposed during the meeting will be voted-out. This is not a problem as a) we leave them on board and b) mere discussion about a problem often helps realize possible hidden issues.
That concludes our retrospective meetings in Blendo. We usually feel good after this discussion, but we are certainly tired. This process offers us a sense of fulfillment, purpose and belonging to a team.
What do you do in your retrospectives?
I love technology and working with people. That is why I am trying to offer as much as I can at the local startup ecosystem and at the same time building Blendo. We are developing a platform to reduce time and effort required to integrate and maintain APIs. Simply, fast and efficiently!
I am co-organizer of the Agile Greece and API Athens meetups and I contribute at the Developer Economics Blog.