SEARCH
»

Breaking business silos through DevOps

'Break down silos between staff, teams and departments by deploying more responsive and collaborative structures' (123RF)'Break down silos between staff, teams and departments by deploying more responsive and collaborative structures' (123RF)

Can Agile and DevOps be used beyond software development?

There’s a joke about an architect enlarging a room, passing the buck to the next guy to iron out the resulting complexities. This starts a sequence where every professional makes a change to accommodate the larger room, responding that the next in line can solve the problems. Eventually it lands back on the architect’s desk, with the advice that the room should be smaller. It’s funny because it’s true: while everyone’s doing their job, nobody is really talking to each other.

This is a common problem in project management. Software developers have found new ways to get around this problem, but can the methodologies of coders be applied to the business world?

Get Agile on your Waterfall

You’ve likely heard of ‘Agile’, a buzzword thrown around like a beachball at a pop concert. In context of our topic, Agile is a development methodology and a departure from the ‘waterfall’ methodology.

Imagine Waterfall as its name suggests: a one-directional flow that reaches various pools, cascading downwards to the bottom of the hill. You can’t swim against the current or reverse course. In Waterfall, a project is typically laid out first in detail, then built in stages. Agile is more like a slip-n-slide, where you can quickly rush to the bottom, then run back up for another go. Instead of laying everything out meticulously beforehand, you set benchmarks, try to hit them, learn the lessons and start again. The advantage of this is that the many moving parts of a project can collaborate and adjust more freely. Agile is quite fashionable, leading to project management systems such as Scrum and Kanban.

DevOps is when you apply Agile while creating more active communication between either development IT and operational IT, or between IT and business. Definitions vary, but one of the most astute explanations, by Devops.com columnist Tony Bradley, is “breaking down silos and finding common ground. That doesn’t mean all the teams have to be restructured under one organisational unit, or even that everyone has to adopt the exact same tools and processes. It means figuring out how they’re different and how they’re alike, and determining ways to make the most effective use of the common ground where their similarities overlap.”

DevOps in your business

Does this apply to your business? That’s an ongoing debate. Philosophically speaking both Agile and DevOps could be applied to environments outside of application development. Certainly if a company is involved in customising or developing applications, adopting DevOps may be critical. Several studies reveal the value of DevOps environments.

A 2013 survey by Puppet Labs found that companies using DevOps deploy code 30 times more frequently and less than half their deployments fail. Since DevOps and Agile are methodologies, not tools or systems, you could morph them into a business context. One piece of advice is to create a cross-functional team that has members from various groups involved in the project. Other elements are to automate menial tasks and encourage the availability of information to all group members, eliminating communication bottlenecks.

This sounds great and may have you itching to rearrange the project right now. But how to do so is still an open question. Some support a dual-speed environment – where different systems run in tandem while one is phased out – while others see DevOps as only workable if it completely changes the cultural framework of a company.

There are other pitfalls as well: poor understanding of staff workloads and unrealistic goals tend to scupper DevOps vessels. But we can take at least one useful leaf from the DevOps book: break down silos between staff, teams and departments by deploying more responsive and collaborative structures where the left and right hands know what’s going on. Don’t enable those making changes to hope someone else will solve the resulting complications. Figure out how to get them to talk and think together in the first place.

SHARE THIS ARTICLE
sponsored by
PRINT ARTICLE
Print
sponsored by