In any organisation, one of the most powerful ways you can empower your team is to give them an environment that allows them to communicate freely at all levels. At Made Tech we actively encourage every member of the team to initiate or join any discussion that interests them, whether it be giving their opinion on how a part of the business runs, or introducing a new way of approaching how we work.
It can be scary to devolve a lot of managerial and planning responsibility to teams but we’ve found lots of positives in changing the way we approach time management. Allowing teams the ability to plan their workloads, holidays, working location and client engagement has resulted in a greater sense of ownership on projects.
As an industry of tinkerers, optimisers and perfectionists we occasionally miss the beauty of unorganisation and human instinct. Our obsession to be more efficient and productive can sometimes have some undesired consequences. At Made we often adapt our processes in the name of efficiency but lately we’ve started experimenting by taking away some of these processes with surprising results.
I spoke last time about the organisational challenges of adopting Continuous Delivery. One of the key takeaways was the importance of blurring the boundaries between team ownership in order to facilitate better adoption. This time around I want to zoom in a bit and focus specifically on the challenges faced by specific parts of the pipeline. Depending on how far through adoption you are, you likely no longer have dedicated teams for each of these functions, though the problems outlined here can still exist and derail even the most cross functional of teams.
Released in late 2013, Remote: Office Not Required by David Heinemeier Hansson and Jason Fried (of Basecamp, formerly 37signals) immediately struck a chord, particularly in our industry. Suddenly it had become acceptable to want to work in places other than the office!
Developers should be allowed to deploy at any time. Many find this a scary prospect since it makes traditional release management and QA very hard. We have found that empowering developers to own the responsibility of deployment allows you to ship software much faster whilst maintaining or even improving the safety of releasing changes when compared to more traditional processes.
At Made we host regular client showcases, this is an opportunity to sit down with the client to discuss how the iteration and the project as a whole are progressing.
Over the past year I’ve worked on a number of projects that have involved some large organisations. By large organisations, I mean, big hefty things that have been around for a while, have lots of cogs and yet still achieve a lot.
At Made, the majority of our projects use Continuous Delivery pipelines to provide a clear path for deploying to production. It’s common for these to be setup on the first day of a project kick-off.
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?