The problem with Continuous Delivery & DevOps as an IT investment

In Thoughtworks we have a lot of experience in implementing Continuous Delivery , and we have done it project after project under some name or the other. In fact we did it long before Jez even wrote his book on the subject. (Jez talks about one of those projects here). I remember roles which we used to call Build Masters/Engineers, even Build Monkeys and teams such as Build and Environments team which practiced the same principle. These teams or roles used to be specialised and sat outside the group of people who delivered functional user stories.

Today we call the people DevOps and the practice Continuous Delivery, but largely we have the same problem as 10 years ago. DevOps is seen as a separate team and Continuous Delivery is seen as an IT initiative. In fact organisations have gone a step further in this direction to appoint IT heads for continuous delivery who are in charge of such teams.

The reason Continuous Delivery becomes an IT initiative

1. Business sees it as an IT investment

In most big organisations business teams are still keep a safe distance from the gory IT details and more so from IT Operations and Support teams. (Business teams have more to worry about in their lines of business). In their view Continuous Delivery is an IT Operations issue solely as it will minimize the operation spend for IT. They see the key driver being within IT and the impact only on the IT operational cost and hence believe that Continuous Delivery should largely be an IT investment and if an organisation wants to do it, the IT budget should cover the cost and not the business.

2. The practice is seen as a mighty legacy systems/operations overhaul

In most large (> 1000 people ) organisations such as banks and insurance firms there are a whole lot of legacy infrastructure lying around. These are systems on which no one has ever attempted writing a single automated test. Deployment is a humongous tight coupled multi-step process which no one has ever imagined being done with a batch job.

In such places an IT organisation has to start somewhere and that cannot happen without a focused initiative. This results in a new department whose sole job is to focus on bringing in the continuous delivery practices into the organisation.

Problem with a separate DevOps team with an IT budget

The problem with a DevOps team funded by an IT budget is that it results in another glorified Operations/Support team, only this time balanced with application developers and sys admins. Being centralised to project teams, this team ends up doing any work classified as "Infrastructure" such as provisioning and configuring virtual machines, optimising and maintaining the build environments, production server monitoring etc...

Product owners, on the other hand, push their teams to deliver more functional stories and encourage them to delegate any "technical/infrastructure" work to the DevOps team. This results in product owners distancing themselves from the benefits of DevOps which is contrary to the whole principle of Continuous Delivery, which is to demonstrate rapid responsiveness to change and hence create a strategic impact for the business.

Moreover some DevOps teams work with a goal to make themselves redundant and merge themselves with functional product lines. This goal often remains an aspirational one with their ever growing backlog of work.On the contrary DevOps teams end up creating their own silo with specialised skills which developers on project teams struggle to keep up with.

There are enough reasons for business to cheer about Continuous Delivery in the longer term. An investment from a business unit will only result in business teams working closely with IT, which is at the heart of Agile and Continuous Delivery. Business teams will be able to find new ways of creating a bigger strategic impact and have an edge over their competition. Hence for the right alignment within the organisation, funding for Continuous Delivery should come from a Business budget.