Pre 2007, developers would create software, and IT operations teams would roll it out. However the disconnect between the two led to slow releases, broken products, frustrated customers and even more frustrated employees. But in 2007, rumours about a new way of working, which included reducing time wastage, improving communication, releasing faster and more reliable software and reducing staff stress, were rampant. It was the birth of DevOps, and with it, DevOps culture. We’re going to look at why not only software companies can benefit from this new way of working.
In simple terms, DevOps is a set of practices, ways of working and tools that were created to improve software development. Their main focus was to remove silos between development teams and IT operations teams, with the aim of shortening the development lifecycles and improving communication and quality of output.
Where DevOps started as a set of process changes, it has evolved over the years into not just a way of working, but a philosophy. There are now roles for devops engineers, devsecops engineers, devops trainers, you can attend devops events, and there is such a thing as a devops culture.
Based on the values of communication, collaboration, transparency and innovation, every type of organisation, whether they are a digital agency, a factory warehouse, or a café, could benefit from understanding and adopting devops culture.
Transitioning to devops requires openness and acceptance of new ideas and new ways of working. To help with this, alongside its values, devops has a set of principles that its followers should adhere to. These include:
A trust environment is one where employees feel safe to be open about mistakes and the company as a whole is willing to learn from failure. In DevOps, it is essential to bring mistakes and errors to the forefront, so that the team can learn from them and they won’t happen again. This idea should be embraced by any organisation - the last thing you want your staff to do is hide mistakes or bury bad decisions that may resurface further down the line in catastrophic ways. Every employee should not be fearful of pointing out something that is wrong, and teams as a whole should take responsibility for their work.
To create a trust environment, you can create sessions like retrospectives or reviews at the end of projects, or key milestones, to look back and reflect on what went right and what went wrong. This should be done without blaming any individual and learnings should be taken and embraced for future projects.
Your team should also be open to continual experimentation. If people within your organisation have ideas of how to do things better, this should be shared and tests should be carried out to see how new ways of working could contribute to improved results. If a new way of working fails, that’s a good thing, as it’s an opportunity to learn what doesn’t work, and get closer to what does.
In DevOps, everything that can be automated, should be automated. If you can automate a task, this speeds up the work, removes human error, facilitates testing and recreating the task.
In your organisation, your employees should be spending as little time as possible on repetitive tasks. If you do something more than once, see if you can automate it. This doesn’t mean coding the automation solution yourself - there are open source programs and tools that can automate a lot of tasks for you and your organisation, freeing up your employees to do the things they are specialists in.
In DevOps, one of the main objectives to improve workflows is to reduce time waste. Waste can include:
transferring information e.g. briefs / comments / feedback
emailing back and forth
having multiple sources of information and not one source of truth
duplication of work or scope of tasks
To reduce this communication waste, get your team all on a call with a client instead of passing feedback from a client to a team member. Reduce email chains and have direct messaging instead. And keep meetings to the agenda points only and don’t go off topic or over your time window.
DevOps promotes the sharing of information. For software engineers, if a developer has a way to automate a task and save the team time, this should be brought to light and shared with the team so the entire team can benefit from the time saving.
Sharing learnings, good experiences or bad, helps everyone progress as knowledge can improve everyone’s ways of working. In your organisation, reviews and retrospectives can be a great opportunity to share learnings from the team. Skills hours or lunch and learns can also be a really useful way to skill up your entire team on topics that they may want to know about but have had no one to show them.
Constant communication between teams will enable a more collaborative environment and will improve the wider output of your organisation as a whole.
DevOps promotes the idea of continuous improvement via incremental releases. In software, this means releasing small and often. This is because it’s:
less risky
less rework
faster feedback loops
delivers higher quality to the end user faster
It is better to do a bit of work, and share it with a client and get their feedback, than to do a whole project over a long period, then share it with the client, only to realise that the brief was misunderstood, and the whole thing needs re-doing.
This idea of delivering little and often, can be applied to any project. It’s better to do a bit, get feedback, then work on that and build on it. That way you are always learning and improving whilst rework and risks are minimal.
As an agency, Creode has fully adopted and embraced the DevOps way of working. It goes hand-in-hand with our continuous improvement methodology and if you would like to learn more about our approach, you can read about it here. If you would like to speak to one of our team about a project, don’t hesitate to reach out to us.
Proud to partner with
