In software development, quick feedback is fundamental, and continuously building, testing and deploying is part of our standard toolkit.
But it isn’t enough to set up and run these processes; we need to pay attention to the results. If we can’t successfully build, test and deploy our software, then we have no idea whether we’re building it right, and we risk releasing broken components. It saddens me how often I see teams that have become completely inured to failures, and the result is a predictable decline in quality and drop in team effectiveness.
Here then are a few quick and easy techniques to start paying attention to these failures.
Set up notifications
Many build and release tools will integrate with communication tools like Slack. If you’re not using Slack, then there are email integrations.
Don’t just set up alerts for failures: relentless bad news saps our will to improve things. Get alerts for all the successes, and celebrate these.
Create a dashboard
It’s useful to see successes and failures as they occur, but after a while the stream of notifications can mask the overall picture, and the signal can get lost amid the noise. This is where dashboards come in. Aim at the very least to show the status of the latest build, test and deploy processes for each of your components. If possible, include some history. Many build and release tools support this natively, but if your tool doesn’t, it’s well worth investing some development time.
Here is a redacted screen grab of part of our dashboard; as you can see, we had a few problems today!
Make your dashboard your home screen
Dashboards are great, but they’re just web pages, and it’s really easy to ignore web pages.
To make sure you see your dashboard more often, set it as the home screen in your browser. Every time you open your browser, you’ll see the latest snapshot of the health of your build, test and deploy systems, and you need only click the `home` button to pull the screen up later.
Setting your home screen is nice, but what about your colleagues? In my team I don’t have the authority to mandate a particular home screen for my colleagues, and even if I did, I would be pretty certain that they would ignore any screen that was imposed on them.
But I can take screen shots. Whenever we manage to get our dashboard completely green, I take a screen shot and share it on our team Slack channel. If it’s looking peely-wally, I’ll also post a screen shot with an encouragement to fix the problems.
Post it on the team board
We want to talk about the status of our systems, and many teams have a daily discussion around their team board. Shortly beforehand, I print a copy of our dashboard with a date- and timestamp and stick it on the board.
Yes, it’s pretty low tech (insofar as colour printing is low tech!) but it gives us a clear topic of discussion and ensures we can’t escape from any issues.
What about buying a build monitor?
Yes, you at the back! I’ve not talked about buying build monitors. This has been deliberate. In some companies it’s easy to buy a large screen and screw it onto the wall; in others, you’ll find yourself deep in a procurement process with no end in sight. I’ve also seen teams blithely ignoring the deepest red of their build monitors. If you’re not paying attention to your monitor, then frankly it’s a waste of electricity and raw materials. My advice is to start with the simple techniques above, and spend money on a screen when these manual interventions have become a bottleneck.