Is DevOps Dead In 2018?

So this might sound like a really odd question coming from me considering most people think I am a DevOps consultant (whatever that means) or that I was running and building DevOps teams before that. The truth is that under the DevOps name I’ve been promoting the idea that, as some have put it “Products over Projects.”

What does this mean exactly? Well if I think back to my early days at Pearson the team and I built a platform we later named “Nibiru”, we treated the entire platform like a product because it was a product. It was an internal product, we had a product owner, we worked off a Kanban board (in Scrumban fashion) and we meet regularly with stake holders to gather requirements and build a feature backlog.

Infrastructure teams or worse yet DevOps Teams still by in large manage work as projects or even worse with tickets. They need a new storage solution so that solution is managed as a project, they might try and implement Cisco ACI so again that implementation is managed as a project. About a year ago I had a conversation with a client that was still managing work as projects in soiled project teams, each team had a project backlog but no one team fully delivered a consumable “feature” by a “persona”.

Building products is a concept software engineering teams have understood for 50+ years now; however, infrastructure teams still struggle with this concept. This is why, in my opinion, most if not all DevOps initiatives fail. Most infrastructure leaders still create “network teams” or “storage teams” or “Linux teams” worse yet “DevOps Teams” but as we mature as an industry successful infrastructure teams will start building products not just field tickets or work on projects.

So, what does this look like? Well it means that the first step in building a product is to define personas or customers and figure out the problem you are trying to solve. For most infrastructure and operations teams this is relatively easy. Your goal is to enable a fast flow of work from development into production, and your stake holders are feature or product development teams which build customer facing products.

The next step is to create an infrastructure development scrum team this scrum team is going to operate much like every other scrum team in the company. There will be a product owner, a scrum master and the engineers who actually do the work.

Again, this is where most infrastructure or “DevOps” teams are still getting it wrong. The DevOps team or infrastructure development team should be a cross functional team. It should NOT be a team of Jenkins engineers or a team of Chef Developers or even a team of AWS experts. A cross functional team should have all of the skills necessary to deliver working software and consumable features by the customer (the feature development teams).

Far too often I work with clients that tell me about their DevOps maturity only to find out they have a “Jenkins Team”, “Puppet Team”, “Linux Team”, and “Cloud Team” and they still wonder why it takes them 6 months to push new features to market.