I was fortunate enough to make my speaking debut at Agile Cambridge 2014. Follow this link for session details.
I attended Agile Cambridge 2013 and was inspired to speak at the conference. I chose to speak about DevOps as I’ve done a fair bit of investigation into the subject and on my travels found some alarming trends and missed opportunities.
- “DevOps is the practice of operations and development engineers participating together in the entire service life-cycle, from design through the development process to production support.” – http://theagileadmin.com/what-is-devops/
- “DevOps is the blending of tasks performed by a company’s application development and systems operations teams.” – http://searchcloudcomputing.techtarget.com/definition/DevOp
- “DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between Development and IT Operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between the two business units.” – http://www.webopedia.com/TERM/D/devops_development_operations.html
- Platform – the tools, infrastructure, containers and environment configuration, including the state of that configuration (e.g. the state of data in the database)
- Deployment – the practice of deploying a built software artefact onto the platform
- Testing – lots of test types, triggers and frequencies
- People – the people who make the three pillars above happen and how they might be organised
The first three pillars may have a mix of manual and automated steps. The fourth pillar, people, are either performing the manual steps or developing the automated alternatives (perhaps with the assistance of tools). It’s not enough to say “manual or automated”, we need to ask how rapid, how repeatable and how reliable.
- Rapid – how quickly a particular step (or series of steps) is performed. Quicker usually means more investment.
- Repeatable – can it be run over and over again? For example, some tests may be destructive or at least change the baseline data state in the database. Do we need to roll-back to a known state or can the tests be written in a more flexible way? Again, this usually means more investment.
- Reliable – when the steps (or series of steps) is performed will it reliably run to completion. There is absolutely no point in automating something flaky. It will just get ignored and wastefully consume time and resources.
- Do we need to automate? What level of service are we hoping to achieve? Is there sufficient investment available? Perhaps define the level of service as NFRs (non-functional requirements) to define them as attributes of the product to be delivered. E.g. deploy new release to production weekly.
- Do we manage people by capability as separate teams or do we organise people around products that are important to the organisation? Breaking down barriers to communication is an important goal in any organisation, but is it more important to bring the people working in a certain way together or is it more important to bring the people working on a certain product closer together?
- Should we invest in standard practices (to promote cost savings) or invest in innovation (allow different ideas for different products to flourish)?
- By product. Provide permanent multi-discipline teams to develop and manage a product at all levels. Essentially a sub-organisation itself. These teams may require expert/specialist support from outside the team from time-to-time, but as a whole the team should be self-sufficient. These teams would focus on the mission critical products: those products that are most important to the success of the organisation. “Bring the people to the work.”
- By capability. Provide permanent teams offering an ongoing capacity & capability. These teams organise around the capability they have and may be dependant upon other teams for delivery. Some of this capability could be outsourced. These teams would work on a particular product for a short time, then move onto another product. Changes to a particular product would have to be scheduled into the available pipeline. “Bring the work to the people.”
By having a choice of model organisations are better equipped to organise according to priority. If the product is mission critical, organise around that. Otherwise it is more important to standardise and equip teams to deliver through a particular capability.
Finally, the new definition for DevOps I offer is…
DevOps is an approach to streamlining the deployment and operation of a product on the production platform. This is enabled through removing barriers to communication, providing self-service operations and automation of steps for a rapid, repeatable and reliable product delivery pipeline.
A DevOps Engineer is a master of this approach and an expert on the tools that enable the automation of the pipeline, preferably operating in a coaching capacity.