Continuous Collaborative Delivery with Go

I’ve spent most of my software career, 12 of 13 years, on the delivery side - the bulk of it in roles where it was my butt if we didn’t deliver or expectations weren’t met (or reset). One of the toughest delivery impediments I had to constantly deal with was the ubiquitous silo. Assuming you have a functional* team, based on trial and error and about 500 “whys”, my recommendation on how to crush silos is to concentrate on the points where work needs to move from one role to another. Delivery management to me is about maintaining a steady flow of the most important work between all roles. It’s amazing how many times the proverbial ball hit the floor or when an exchange was never attempted.

I’ve had a chance to work at quite a few companies. Each company is a snowflake but there were a handful of common things that obstructed the flow of work.

• Distributed team. It sucks to throw things over the wall (black hole), wait days to get information that only the silo over there knows, lose more time due to misinterpretation, a forgotten reply, etc.
• Email. It is the worst way to keep work flowing. A distributed team exacerbates the email problem.
• Tool constraints. It was never fun when a tool wouldn’t let us work the way we wanted.
• Too many tools. It was never fun to have to look at a bunch of tools to troubleshoot common scenarios or find out what’s going on.

I’ve tried a bunch of ideas and techniques to deal with each obstruction. Some failed, some worked, and some worked really well. In terms of the flow of work in the Build-Test-Release part of delivery, Thoughtworks Go really impressed me**. It doesn’t fix everything listed above in entirety but it significantly helped.
I saw developers, testers, analysts, release engineers and operations regularly get together and use Go to create and modify a common workflow. A single team formed across multiple time zones! Very little was left in anyone’s head. This fixed a significant chunk of our distribution problem.
Their workflow included activities (to fail fast so they could learn fast), how things should flow into the next role, manual gateways, and security. Soon everyone understood their relevance in terms of the big picture and the importance of every other role. Go provided a view for everyone to see what’s coming their way, what’s broken, how much work is left, etc.
Everyone was able to self-service their steps in the entire Build-Test-Release workflow. Yes, the auditors were happy.
All of this reduced the reliance on email to keep work flowing.
Go never got in the way of the team’s ability to define and tweak their workflow.
Since Go handled Build-Test-Release, it made it really easy for me (delivery manager) to answer holistic questions around progress and bottlenecks, and follow the flow of work across roles.
Go helps crush silos and keeps work flowing. And, if you are accountable for delivery, trust me, it makes writing status reports easy.

--------------------------