paint-brush
How I introduced an information radiator to my distributed Scrum teamsby@mpvvliet
3,674 reads
3,674 reads

How I introduced an information radiator to my distributed Scrum teams

by Martin van VlietSeptember 16th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<strong>UPDATE</strong>: check out the tool’s website (<a href="http://sprintlr.io/" target="_blank">http://sprintlr.io/</a>) if you are interested.

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - How I introduced an information radiator to my distributed Scrum teams
Martin van Vliet HackerNoon profile picture

UPDATE: check out the tool’s website (http://sprintlr.io/) if you are interested.

Companies are increasingly hiring remote engineers to battle the talent shortage. Having been an engineering VP for the past 8 years, I can attest to this first hand. Almost every team I’ve worked with had one or more team members that were 100% remote. Given the demand for good engineers, this trend will likely continue in the future.

The tools distributed development teams use to collaborate have improved tremendously. Tools like Skype, Slack and JIRA are used instead of co-location and physical Scrum boards. Distributed software development teams are now mainstream.

But there is one thing I’ve found hard to achieve with a distributed team. How do you foster shared understanding of a development team’s status and progress?

With co-located teams, I’ve used “information radiators” in the past. These Big Visible Charts (BVC) were posted on the wall in the team area or at the coffee machine. Team members would get an update about team status while waiting for their brew. This information enabled them to make tradeoffs that often determine the success of the sprint.

Distributed teams lack a shared physical space to share this type of information. Yet they spend almost all their time online in Slack. This got me thinking about using Slack to distribute an information radiator. Just like a regular BVC, the information would come to the team rather than the team having to go look for it. It would display a visual summary of the team’s progress. The actionable information it contains can be used in a standup, planning meeting or retrospective.

I decided to build a tool to do this.

The tool collects sprint status information from JIRA, producing a concise summary. The formatted message is pushed to the development team’s Slack channel. It appears right in time for the standup so the team knows exactly where it stands.

Here is an example of a sprint update in Slack:

As you can see, the sprint update includes an up-to-date sprint burndown graph. The graph tells the team how it is doing on the sprint forecast. If there is a lack of progress, the graph prompts the team to discuss alternatives. It may also spark a discussion with the Product Owner to reduce sprint or story scope.

In my experience, development teams that keep track of their sprint burndown are more likely to finish a sprint successfully.

The sprint update also shows a summary of blocked (flagged in JIRA) and in-progress stories in the sprint. Blocked stories prevent sprint progress and should be part of the standup. The sprint update can be used to run a standup meeting directly from Slack, without the need to switch to JIRA.

I have a lot of ideas for further expansion of the tool and I will share my progress here. If you would like to know more about the tool or have experiences to share, I’d love to hear from you.

Martin works as VP Engineering for StackState where he and his teams are building a next-generation monitoring and AIOps product. As a side project, Martin built techfu.io, a tool to automatically assess technical talent.