When you have been in the software industry for a while, you become familiar with the plethora of buzz words that pop up over the years. Some have been successful and stuck – like ‘Agile‘ – whilst others like “Web 2.0” remain cringeworthy in my book.  

Most buzz words don’t trend without good reason. They start out as good solutions that gain popularity as word spreads about their implementation success. The problem starts when companies start touting these solutions as panaceas for all.  

‘DevOps’ and its children <INSERT LITERALLY ANYTHING HERE>Ops fall into this category but what is DevOps, really?

First, an official definition from everyone’s favorite source, Wikipedia: 

“DevOps is a set of software development practices that combine software development (Dev) and information-technology operations (Ops) to shorten the systems-development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives.” 

That sounds like something an organization would definitely want, but how does it work in real life?

For me, DevOps boils down to delivering better-quality products quicker by:

Enabling the right team structure and workflow

The more layers and separations an organization has, the slower it will progress. This is a known fact. Just take a look at how many larger organizations create smaller ‘accelerator’ units with less cumbersome organizational structures so they can go faster.

One common software project team setup illustrates this problem perfectly. Software project teams are often set up in three separate units split by areas of expertise. 

  1. Front-end team 
  2. Back-end team 
  3. Quality Assurance (QA) team 

However, with this structure, when it comes to adding a new feature, no one takes ownership and it becomes a game of pass-the-buck. The front-end and back-end teams each do their parts in silo, and hand it over to QA to test. When QA finds issues, the bugs get assigned back to the teams to fix. This sounds trivial, but this back-and-forth is time consuming and can be unproductive. How long would it take for your software to be ready?

In a DevOps team, the aim is to function as one unit, all travelling together towards the same goal. While there may be experts in certain areas there are no longer these organizational lines to restrict efficiency. 

Taking my example above, just by having the development team work as full-stack rather than front-end and back-end, the problem is solved. Each engineer has full ownership of a given feature and any issue resides with them end-to-end. The onus is on the developer to test the feature fully before QA to minimize errors and speed up the whole process.

Improve efficiency through automation and enable focus on higher value tasks 

Humans are lazy, and it is human nature to want to get things working as quickly as possible. People tend do things hastily and make a quick fix when problems occur rather than take the time to build it properly from the start. 

This is an ever-present issue in software development where something is broken in production – alarms are going off, people are screaming at each other, and the fix needs to get out ASAP. 

What typically happens is a manual intervention: some modification is made on production to the code or infrastructure to resolve the problem in that moment. When the problem is resolved, the issues are instantly forgotten, never to be remembered again. Over time, the manual fixes pile up. When the code is re-generated, someone needs to painfully revisit the manual fixes and carry them out again. 

DevOps on the other hand, identifies and automates simple, repeatable processes. This reduces manual errors and allows the team to focus on the real issues that pop up.

So… should I Implement DevOps?

DevOps is not a magic pill that cures all. No matter what anyone tries to sell you, DevOps is not a product or a tool you can purchase off the shelf – DevOps is a way of working. 

To transition from a traditional model of working to DevOps requires a fundamental mindset shift for all involved. From my experience, this mindset shift has often proven to be extremely challenging. Business leaders need to be able to commit to and invest in a changed way of working.

If you are exploring implementing DevOps, rather than dive straight into an extensive and complicated transition, get clarity on the fundamental problems you are trying to address and have a clear view on the potential impact of implementing DevOps for your organization. 

Biqmind Discovery Workshops provide a neutral forum for business and technology stakeholders to rapidly build a strong foundation for transformation by visually mapping best routes, developing common understanding, and capturing actionable requirements. Learn more<cross link>

Andrew Whiteside
Author

Andrew Whiteside

Innovative and focused, Andrew Whiteside has a 15 year career in software development / management and systems architecture. He understands the pains of development teams first hand and is able ​to provide a practical perspective on how to support teams in transitioning to new tools, technologies and approaches. An engaging and inspiring facilitator, he is a subject matter expert on areas such as Test Driven Development, Pair Programming, Scrum, Kanban, DevOps, CI/CD, Domain Driven Design and Evolutionary Architectures among others.

Scroll to Top