The problem was I got very over-enthusiastic and the blog became very long. Hence I’ve broken out describing why a DevOps Service team is a pattern here.
I described two valid types of team
- One that provides an appropriate set of services to Development and Operations (on-going). Described here.
- One that runs a change programme to expedite adoption of Continuous Delivery (temporary). Described right here in this blog!
DevOps Change Programme Team
For some organisations, depending on how far they have to go, some steps towards Continuous Delivery will just be too hard to deliver from one of the core teams or a service.
Creating a DevOps programme/project team may not be for everyone, but is a valid endeavour. Such a programme would take end-to-end ownership of increasing Continuous Delivery maturity and achieving a globally optimised IT function. Programmes may bring a number of advantages. By requiring investment they automatically incur a level of expectations for senior folk which can help establish credibility i.e. that this is really happening.
The success of the programme should be measured by three outcomes:
- the programme-assessed improvements against the original baseline,
- the recognition of those improvements by Development and Operations, and
- the general view of the outcome from Development and Operations.
Projects making up the programmes could include analysis of current processes, taking a baseline of current performance and performing R&D on tools and processes.
R&D is interesting because it can achieve a lot without even looking outside an organisation. Most organisations will have systems and processes of varying maturity which provide ready-made case studies of what works and what does not. They will also have people from a variety of backgrounds and experiences combined with context specific insight into how and what to improve.
Projects can be used to set up the acceptable services listed above. I’d even go a little further to say my test 1 about not abstracting people from their core responsibilities can be temporarily relaxed (pending later correction). For example if introducing a major new tool like Puppet or Chef the level of effort may warrant temporary extra assistance from a dedicated experienced team to write the first cut of configuration files. Obviously this must be done with caution and mindfulness of the need to transition back responsibilities to the rightful owners.
Programmes also have a natural advantage of being painfully aware that they have to convince both Development and Operations that have their best interests at heart. Staying on the subject of introducing automated Configuration Management tools, when these are driven from Development, they face an almighty challenge getting taken seriously and anywhere near the production environment. When they are driven from Operations, the sell to developers that they now need to taken previously Operations concerns is not an easy sell. When they are driven by an independent team, these concerns need to be addressed openly up front.
A well executed DevOps Change Programme can be very effective and having a DevOps Change Programme Team is a Pattern!