SI Process Hacks – The Internal Product Changelog

Development is hard. But communication is even harder – especially across departments and continents. Our SI Process Hacks series will highlight a few simple hacks  we wish we had known right from the start!

The problem

We deploy many times a day –  bugfixes, feature improvements, new options, changes in user flows etc. As a developer, you know when you committed, and you can see your commit go live in real-time:

Screen Shot 2016-07-03 at 13.23.56.png

But as the developer on another subteam, or especially as a non-developer, git-hashes are not really your preferred way of looking at things. It’s tricky to know when what change goes live on what day. Knowledge of changes is crucial, you don’t want to demo the product to a potential client and get caught off guard by that new button on a core screen.

We tried using Slack to keep people in the loop, we considered using a special Trello board, or including even tiny changes into our Release Notes. But everything was just complicated and never quite flexible either.

Our solution

In the end we came up with a really simplistic approach:  We have one single Confluence page that acts like a stream. Every developer adds brief summaries of customer- and support-facing changes to the top. Really important changes get communicated via Slack too, but it’s not mandatory. Every customer-facing person watches the page and gets automatic email updates.

Screen Shot 2016-07-05 at 22.54.26.png

 

 Aaaannd this is really all that’s required. It’s simple, it’s real-time, and it’s flexible too: Want to include a reference to a Trello, to a public post, or whatever? Check. Need to mention someone by name? No worries. As for clarification? Confluence inline-comments to the rescue. Want to notify people a day earlier? Put in a note above the timeline.

The main advantage over just using Slack is that the stream remains clean. No replies, reactions or funny gifs will mess up the timeline! So as a support engineer coming back after two weeks of vacation, you know exactly where the product is at.

And that’s even great for developers on the other subteam too.