and why Trello?

Lately I’ve started using Trello as an ultimate tool for the Retros and Demos. So this post will cover the path to using trello as opposed to other solutions.

Tools

I’ve been using multiple tools, such as Realtimeboard (now Miro) as an interactive flipchart to collaborate with the team, Google Docs with sections appointed to the retro stages, Confluence (as in 100% of the projects I’ve been working in we’ve had Atlassian stack), even Jira once (wow that was a bad idea)! 

I bet almost everyone was trying to find that nieche, that ultimate tool he can expand to using in various projects no matter the area! 

The main criterias for the proper tool are: 

1. handling item-centric discussion -> cards, ideally.
2. fast and effortless collaboration of the cards
3. markering the cards (by all members), no matter label or color
4. cards reordering
5. time spent on executing action of: creating section -> adding item -> labelling it to be worth (by members) -> adding comment to the item.

Realtimeboard

While Realtimeboard is awesome, it’s not as simple to use in collaboration (well, it exceeds in functionality but format of retro is tied to the cards which is not the strongest of that product’s sides). There’s no barebone structure that supports cards, so you have to maintain it yourself: create some kind of a column, move items that are not self-aligned to that column. This is time-consuming and effortless. Labelling is not a stronger side of Realtime board.

Google Docs

When it came to Google Docs, it’s the default option for zillions of companies I’ve discussed remote retros with. However, it’s not visual enough from the point of dissecting retro items and splitting them. Using spreadsheets on the other hand seems to cope better with 2-dimentional-retro-approach (well, not an approach but the idea that you got buckets with items for good/bad/improvements). However drag-n-drop for the items to reorder and link with each other sucks there. I’ve also tried to have Google Slides at a certain point with one-slide-per-section (e.g. all great improvements accomplished since last sprint) – but it seemed too heavyweight and kind of sucked at limiting members of the dev team to collaborate properly. Labelling here is somewhat ok, but

Confluence

Coming to confluence, albeit it does have a blueprint for the retro – it’s good more for the documenting / stenographing, than for the real-time-discussion. Or just writing some kind of decision-log. Atlassian tries to position confluence as a lightweight in-stack solution for collaboration, however it’s far away from gDocs in terms of simplicity/stability/collaborating. And again, it’s not centered around discussion items. It’s also not stable enough, where some of the changes are not applied on publishing, or connection is lost to cloud instance. 

Trello

Coming to Trello, it simply supports the cards, it allows voting either via power-ups (which is simple), or via labelling with colors (which is fast, efficient and convenient). You can drag-n-drop item cards, and organize Retro stages into column. If the item may have a lengthy discussion or not that related -> you just drop it into the parking lot. Basically, trello is the most simple-to-use online implementation of flipchart + stick-it-notes.

Preparation & Setting the Stage

Remote retros usually are much less emotional and empathetic, given that it all happens online and some people may not want to share their faces (and expressions) behind the camera. Now to set the stage, we’d ideally need to:

• Get everyone to turn on the cameras at their laptops
• Select comfortable tool. I usually use either Skype or Slack video, but occasionally zoom seems to be a great option as well
• Make sure the quality of connection is superb: we need as less lags possible
• Prepare beforehand: either with the unified agenda, or the topics. We can preliminary pinpoint any inconsistensies and disfunctions on an online board 🙂 All members of the retro should know the structure of how the retro will be proceeding, in order to assign points they’ve prepared to particular retro stages.

Retro

Things improved since the last sprint

I usually start retros by listing our improvement/accomplishments that we’ve planned to achieve last time. So we either mark something achieved with green (we got a long list of all improvements implemented), or mark with orange something critical that we didn’t achieve but planned (and with red if it was not improved for 2 sprints in a row). Later on this red labelled card simply is the top-priority to improve (if still relevant).

This shows the team where we at with desired improvements and is a good starting point for overall recap of things that happened during the sprint before the current one.

Tip: it’s also sometimes nice to order everyone a pizza for the retro to get the positive vibe and thank for accomplishments. It shouldn’t be only on org budget, the team can self-organize around retro being a cheerful and friendly event, instead of a mandatory meeting. Although, don’t force it into the “mandatory-pizza-meeting”, with the management looking from above and yelling: “Eat your food and report on bad things happened during this sprint”. I’ve seen some orgs giving the budget for pizza and overwatching that it’s spent properly (eaten) and making sure people are thankful that management is spending money on their food 🙂

This stage may get lengthy as if something planned to be improved is not achieved -> team may start getting in lengthy discussions on why this happened. As a facilitator, your job is to help team find the productive path to navigating to the root cause in a short enough time to accomodate retro timebox. That’s why only a few items (1-2) should be planned for improvement, otherwise we may be stuck on the very fist stage. Your job as a scrum master is to coach the team to be aware of the timebox and get to the root cause efficiently.

Sprint Metrics

Sprint metrics is an important internal-SLA for the team. Usually there are various factors that dev team may see as an obstacle or an impediment to be an even greater power-ranger-squad. Facilitation and proper reflection of dev team’s discussion provides sufficient items on how to improve the process and measure those improvements. The rest is just comparison. Common metrics to compare are: Lead Time (as soon as you explain the team the meaning of it, team will start to be motivated to improve this metric), time in Code Review, # of times tickets are reopened, and so on.

For bigger projects we’re also reviewing the metrics until the project-end, comparing projections on finishing via story points, and throughput.

Sprint Goals

This is not something that I use everywhere, but still when it comes to transparency, we need to reiterate what we tried to achieve goal-wise. Although this is not directly related to the process itself, since goals achieved need to be reviewed and discussed during Sprint Review -> it’s still effective to hightlight reasons on meeting sprint goals or not (which are related to the process, and retro is about inspecting the inner processes and tuning them).

I usually guide the teams to mark sprint goal cards with green for achieved, and red for not. And comments to demonstrate the reasons. Simple as that 🙂

Typical ‘What have been working nice’, ‘What could have been better’, ‘What will help us improve in the future’

Distributed and remote team members need to add points and vote for them as soon as the issues are found. No need to wait until the retro itself, to pin discussion item.

As a facilitator, your job is to turn team’s attention / highlight any conflicts / impediments during the sprint when the team faces them. Help the team to document / pin it to the retro board.

Do it via reflecting the situation when discussing it with the team, providing a view from a person that doesn’t have a context, or any other facilitation technique 🙂 Make sure team is engaged in inspection process during the cadence itself, and not during the retro event only. And help the team to document / pin it to the retro board. Even if it would lead to a lot of items in retro – you can always remove irrelevant.

References and helpful things

• Ben Linders has a pretty great trello board that provides crowdsourced ways of retro-handling https://www.benlinders.com/news/trello-board-retrospective-techniques/ That possibly was the best help I got when trying to make team retros in trello better 🙂 He’s a nice guy in person, you can clarify a lot if you’re at the same conference / workshop as him!