DevOps does not mean employing “super admins” (despite what the recruitment agencies may say!) DevOps also does not mean building another silo (the “DevOps Team”) alongside other silos – although a DevOps team done right can be a catalyst for change.
DevOps isn’t about throwing Dev and Ops together (like throwing two atoms together the reaction is somewhat nuclear in nature!).
What DevOps does mean is cultural and organisational transformation, underpinned by appropriate automation. Yes – you may have heard this all before but how do you go about doing this if you are not a start-up? And how do you do it at scale?
Well the catalyst for this is a good DevOps Coach, preferably someone Agile, but also with a strong business, as well as technical, skill-set. But then what do you do next?
Let me start by drawing a picture, some of you may recognise, consisting of many Development teams reliant upon (surrounding?) an (in-house or outsourced) Ops (or WebOps) team:
This is the typical silo formation that the DevOps movement was formed to alleviate, and there is chapter and verse elsewhere on the web as to the problems with this.
A typical “first step” in the DevOps transformation journey is to “make available” Ops to the development team (where were they before?). This involves tentative bridge building between the functions (breaking down the “wall of confusion”), some relationships forming and, if progressing well, suggestions from the inside on how the Dev and Ops relationship can be improved. This is a recognised DevOps pattern – Ops feeding into the Development backlog and Development feeding into the Ops backlog (also known as “design for operations”). This is also why Agile/Scrum is a good fit here, a backlog of Dev and Ops items woven together, as well as the Scrum ceremony feedback loops to measure and improve. This is when the kindergarten-style flower begins to appear:
“But this wont scale!” I often hear. The Ops team feel swamped by all of the requests from the Development “petals”. Ops may not have the capacity to support this model in the short term but the worse thing you can do is remove the petals (“they love me, Not!”). Instead the flower should be allowed to “grow” into something more cohesive with previously disparate Development and Operations teams pulling together a structure to improve overall delivery flow. Natural selection is the order of the day here, with individuals from Development and Operations (and ALL functions of operations too – Security, DBA, Audit, etc.) forming cohesive teams based on their current point in the delivery lifecycle and with business aligned goals. This is all augmented through a common sense of purpose and compliance with central standards (the double underlined “stigma” in the flower below – quite an appropriate word!).
Our flower now begins to take shape:
But what is the glue that binds all this together? A cross team Scrum-of-Scrums with a focus on DevOps is a good example. A DevOps community or “guild” is another. Even some of the Agile-at-scale concepts can be applied. Improved communication is the key however – every touch-point in our flower is a new group of communicating individuals who have aligned to address the businesses objectives.
At real scale you will see multiple flowers starting to appear – all joined at the same “management” stem. A stem that channels new ideas, new business objectives and new constrains, but that also shares ideas, problems, opportunities and challenges. Our flower now starts to look like this, a strong (and growing) “plant” of DevOps capabilities joined at a co-ordinating management stem:
In my next blog I will write about some of the “bees” that flutter across these flowers within organisations than can cross-pollinate new ideas and solutions but that sometimes can also cause the flowers to wither and die….. watch this space….