We’ve discussed what Continuous Delivery is, the benefits, how to prepare your team for it, the challenges you may face adopting it, the tools you can use, how to build your pipeline and what you can do to make sure quality remains high, but how do you stay on top of the advances in Continuous Delivery?
Here at Made Tech, we’re always trying to improve. We continuously question our own processes and implement (or remove) processes to eliminate pain points. This isn’t about using the newest tech you read about on Hacker News. It’s about letting people do their jobs better in order to deliver software faster. So, how do we continuously improve?
Sprint retrospectives are an important part of not only a project lifecycle, but also how we continue to improve and iterate on our processes. After every sprint, we sit down with the product owner and our scrum master for about half an hour and look back over the sprint.
What went well? What went badly? How could we improve? Our scrum master comes up with novel ways for people involved in the project to vent about pain points in the previous sprint in a constructive, solution-orientated atmosphere. Each retrospective ends with a list of actionable ways to improve, and if previous improvements from earlier retrospectives were found to be particularly helpful, these can be rolled to other project teams.
Retrospectives are a great way to find processes that end up doing more harm than good, too. As with everything, it’s about finding a balance between structuring developer’s output to maximise efficiency, while also making sure the processes aren’t getting in the way of delivery. It’s only by spending time sitting down and talking about what’s working and what isn’t that we can continue to improve delivery.
Dojos, Katas, Mobs and Talks
It’s important that your developers continuously improve, too. After a certain amount of time working on a project, even the best developers have a tendency to settle into their own ways of doing things. Some developers can also be resistant to change. In order to improve going into the future, it’s important to make sure that developers are all on the same page in regards to best practices, techniques, and maybe even languages and frameworks.
It’s also important to get the most out of your developers. People who develop software for a living often have a lot of things to bring to the table outside of their project work. Looking into the future, talking about and honestly evaluating new technologies as they mature is an important part of staying afloat in the quickly moving technical world.
So what do we do about this? Every Friday, everyone who can spare the time is encouraged to join one of our group programming sessions. These are always organised organically, by people who want to talk about something with the team. These are usually organised loosely into one of the following categories:
A Code Kata is simply a programming exercise wherein a problem is taken, solved, and iterated over until it is of production standard. We usually use TDD to solve these problems. Everyone in the group has a chance to provide input. The goal of the exercise is to get everyone on the same page, programming-wise. Code Katas are a big help for onboarding and demonstrating the standard of programming required at the company. No-one writes bad code when there’s other people watching, especially when the problem is designed to encourage good programming practices.
Our Code Dojos are usually long-running projects which are completed over a series of weeks. We divide an hour up roughly into chunks depending on how many people are attending. The laptop is then passed around so each person has about 5 minutes to contribute to the project. The goal is usually to get everyone on the same page in regards to how we deliver software. Contributors are forced to commit early and often, lest their chunk of time go to waste. A good Code Dojo shows how quickly a project can take form without a long planning period, and helps developers get over their fear of uncertainty.
A Mob Programming exercise is similar to a Code Dojo, but it’s with everyone around the same laptop, making cases for their ideas and then implementing them. Everyone is around one laptop, so the team is forced to work together, building on each others ideas. We often use Mob Programming as a way to refactor some of our existing code.
Talks and interactive demonstrations
Talks and demonstrations give the team a chance to air concerns about new technologies. We can decide if they’re right for us. Gentle introductions to new techniques and technologies can help to ease any resistance that team members might feel. In our opinion, organically improving beats company-mandated improvement, hands down.
So how do we find time to eliminate pain points? Where do we get the time to try out new ideas? If our sprint retrospectives bring up pains in process, when can we research tools that might help us, or develop our own?
The answer, for us, are ‘Thirty Thursdays’*. Our developers, barring emergencies that need immediate attention, have Thursdays to develop ideas of their own choosing outside of project work. Usually there’s a Thirty Thursday pitch meeting, where people pitch their ideas and recruit other team members to help them. We’ve used the time to produce learning materials, canary builds, implement automated visual regression testing, and even make what you’re reading right now.
State of the Art
New technology is always a big part of looking to the future. Technologies are increasingly born, hyped, and killed in ever-quicker cycles. It’s often difficult to keep up with what the “state of the art” actually is. The best techonologies still stand the test of time, but often the level of corporate hype around certain companies’ offerings can make it difficult to distinguish the soon-to-be-replaced tools from the tech that will stand the test of time. We use a few techniques to figure out what technology is worth trying out and what is worth leaving.
Firstly, check the source code! Have a look (or have a developer look) and see what you’re using actually is. See how it works. See how easy it would be to fit into your existing workflow.
Secondly, are your favourite high-profile developers talking about it? Are they excited about it? Most importantly, are they using it in production? Has anyone written about the use cases that the technology is best suited to, and are you sure that you aren’t trying to shoehorn it into your workflow simply because it’s the “hot new thing”?
Thirdly, check out Technology Radar. They publish a monthly list of techniques and technologies to adopt. They’re very level-headed about new tech; they’ll advise to “trial” certain technologies and reassess them as they mature. It’s a great resource.
In conclusion, there’s no foolproof method for ensuring that your company will adapt perfectly in this ever-changing industry. Hopefully the ideas outlined here will have given you some ideas, but ultimately every company works best in its own culture, and the points above are best treated as ideas to help inspire techniques that could prove useful to your company in their own way. In other words, Your Mileage May Vary.
That said, we believe that the general concepts we’ve outlined should stand the test of time. We’re very proud of what we do here at Made Tech, and we believe strongly in our culture. A big part of our culture is about sharing what we believe makes us effective, and our series on Continuous Delivery has been our biggest example of this principle so far. Of course, delivering quality software is a business with innumerable facets, but we hope you have found it valuable. Thank you.
* the name ‘Thirty Thursday’ comes from a fleeting moment of terrible maths. Somewhere along the way, it was declared that one day out of a five day working week is equivalent to thirty percent of a working week, and, more importantly, ‘Twenty Thursday’ doesn’t roll off the tongue nearly so well.