Agile Transformation
Kanban should be the default choice for DevOps teams 
Jasper Gilhuis 06 Aug, 2014
Share 
Let us introduce you to 7 “habits” that might seem like smart ways to do DevOps at first glance but, in reality, and practice, can actually lead to an ineffective DevOps team. In this blog series, we’re unpacking seven of those scenarios so companies can learn how to do DevOps right. So, let’s dive into the first habit!
If a company has DevOps teams — and that’s the only thing they have — perfect! Because that is the right way to go: streamlined teams, responsible from A to Z, that create the requirements, build and deploy the product, maintain and run it, and make sure it keeps running. That full scope is what DevOps teams do.
Unfortunately, as DevOps consultants, we meet with many companies that think they already do DevOps because they have a group of people doing DevOps. Often, their internal team of developers is called a DevOps team, but it only does development. They still have an operation team that does operations. In other words, the developer team is "rebranded" as a DevOps team, but nothing has actually changed in how the company works.
Organizations create these so-called DevOps departments next to their development or engineering departments that only take on certain roles in the DevOps cycle. Often these rebranded operations departments do automation deployment into production — the kinds of things that a true DevOps team should be fully responsible for, from start to finish, for that product.
These companies often have a separate developer department and a business department that defines the requirements or an operations department where they do different things, like network, database, server maintenance, windows maintenance, and Linux maintenance. DevOps for them means the people that are actually building, for example, pipelines. But that’s only a part of DevOps.
The Value of DevOps
To truly do DevOps, it has to be end-to-end. A DevOps team that is truly responsible for delivering a software product end-to-end is incentivized to build better-quality products. They’re focused on business functionality and also on operations. Whereas these pseudo-DevOps departments create a lot of rules that all the teams need to comply with, and that just slows everything down.
Because they’re end-to-end responsible, true DevOps teams continually improve themselves and their products. They start doing things like automation, which gives them more time to actually build business features and deliver more value to the customer. And that’s what it’s all about. DevOps is all about delivering value.
Recognizing True DevOps
Having a DevOps department that is not really a DevOps department or team is fooling yourself and actually creates unnecessary processes and poorer quality because it’s not streamlined. So, if you "have a DevOps team" but aren’t sure if it’s true DevOps, ask yourself, "Who’s responsible for the application? Is it two teams?”
If it’s two teams, then it’s not truly DevOps because each team will have its own very different KPIs. For example, the development side will have KPIs on how fast they can get new business features in, and the operations side (often rebranded as DevOps departments) will be more focused on the stability of the production environment — like no outages. So, if one team wants to change as many things as quickly as possible, and the other wants to maintain stability, you have a conflict of interest. When instead, you create a single DevOps team, it will make its own decisions that balance and include both perspectives. This holistically-focused team will be incentivized to improve the quality of the application for business value.
Investing in DevOps
If you really want to get the benefits of DevOps, you can’t simply add a department that helps do some of the things that typical DevOps teams do. It requires a much larger investment in thinking about and redesigning the whole way your company operates. Invest in learning by talking to experts who can tell you how to specifically do DevOps in your organization. You can start small, with one team, and make that team solely responsible, then see how that goes. When you really want to have teams shine, you need to give them the autonomy to make their own decisions, then they can move a lot faster. This autonomy requires management to enable organizational changes, otherwise, people will become demotivated by uncrossable boundaries, unnecessary red tape and unexpected hurdles. True DevOps is really a matter of thinking about everything.
Disclaimer: Changing is a bigger challenge than reading a blog post!
When it comes to DevOps, there are no cookie-cutter solutions. But it’s definitely worth exploring how to do DevOps the right way for your company specifically. If you’re interested in learning more, please contact us to chat about your team’s needs and how we can help.
Until then, tune in next time to find out why "we make sure security and compliance are done at the end of every project" is the second habit of a highly in-effective DevOps team.
