Main bullets are: – Growing trust in distrubited teams is hard, but nevertheless as important as in co-located team. – Team itself creates an atmosphere of trust in itself. Our task, as a scrum master, coach, manager – is to help and highlight needed areas. – XP and especially Pair Programmingи helps in growing trust. – Intrateam trust, from the informal side (skype beers, navigating as a guest to your colleagues in other locations, bike fixing via the webcam, ordering stuff on flea market in your city and sending it over to a colleague) helps a lot. – More freedom for the team, for collaborative work and motivation. More trust! Work harder on understanding the context and value of features implemented.
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.
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!
markering the cards (by all members), no matter label or color
time spent on executing action of: creating section -> adding item -> labelling it to be worth (by members) -> adding comment to the item.
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.
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
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.
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.
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 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.
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!
This is an interesting case I always wanted to make better: almost every project you come to has a lot of older unreleased tickets, that actually already sit on production. And developers (without proper jira management) continue using the Kanban board that becomes more crowded in the Done / Closed column (and it can hit 400, 1000 tickets and be slow and almost pointless to use). Typical story, huh?
So what to do, if you want to release all those older tickets and don’t bother developers with, say, 450 updates on every ticket that fixVersion has been set to each one of them? The answer (and thanks to AUG Moscow Community) is to swap notification scheme for related projects while releasing.
So we’ve been measuring story points estimate and throughput through the last 5 sprints, and they really do show approximately similar results 🙂 makes you think why do have an additional story points layer on top of the simple throughput? 🙂
It’s been an extremely fruitful Atlassian Summit 2018 in Barcelona! Main purpose was to speak about Distributed Teams, however the atmosphere was so cheerful and friendly, that it was more like a fireside chat, even given that my speech was the closing one.
Talked with zillions of new people from Atlassian Marketplace, Bitbucket, DevOps, Jira Cloud, Adaptivist, Code Barrel, and loads of other Atlassian-related-folks (including long speeches with Mike Cannon-Brookes (WHOA!) 🙂 Met AUG Leaders from all-over-the-world, and the whole atmosphere was sheer cozy and welcoming (you guys were awesome)!
I spoke with Ben Linders of InfoQ (thrilled to be published at that website!) about challenges and communication patterns for Distributed Teams, uncovering bits of my Atlassian Summit 2018 speech.
The biggest challenge of distributed teams is communication, which is essential for establishing ground rules on collaboration. Shifting working hours to accommodate each other and team liaisons help to communicate and synchronize work. Teams based on trust, respect, and openness will thenselves to help people throughout the organization and foster a culture that keeps teams in sync.
InfoQ spoke with Kiniabulatov about the challenges of distributed teams, how product owners and stakeholders collaborate at SkuVault and how the workflow is managed, how distributed teams communicate effectively and synchronize their work, and how SkuVault nurtures a culture that keeps teams in sync.