DevOps Leadership 1: Product Thinking
Product Thinking and Service Design in DevOps
In this post I will show how Product Thinking can optimise DevOps activities, such as the design, implementation and operation of delivery pipeline or infrastructure.
In a world where most organisations want to deliver software ever faster, in controlled manner and based on modern software engineering concepts such as microservice architecture, test automation or containerisation, the building of DevOps capabilities and implementation of a CI/CD pipeline and infrastructure as underlying ‘delivery mechanism’ has become primary or secondary activity of literally every project we work on these days.
However, in many cases specifically the building the CI/CD tooling turns out to be suboptimal— outright painful in some cases — which I believe to be a result of a lack of formal requirements analysis and product thinking within the DevOps discipline.
Delivery pipeline, the elusive beast
What is a ‘delivery pipeline’?
Delivery pipeline is the combination of roles, principles, processes tools and technology to enable high quality software delivery from a user’s needs to a business person’s brain via developers’ machines to production environments into the hands of user as well as capabilities to provision and manage the infrastructure and tooling needed to operate the resulting application at performance and quality, with high confidence and in highly controlled and repeatable manner as to maximise early value delivery and feedback (improvement) cycles, and ultimately user and consequently business value.
(If you have no clue what I am talking about read The DevOps Handbook, this about CI and this about CD. Or best start with the Phoenix Project).
The challenge lies elsewhere…
Counter intuition, the challenge is not a technical one, i.e. building pipeline or infrastructure, but defining the ‘right’ thing and subsequently managing implementation and operation within the respective organisational context.
Please note that I appreciate that DevOps is hard: it is a complex, fast-moving, highly skilled, specialist discipline. The point is that even with excellent DevOps engineers it is not easy: I think, there is something missing.
In fact, we see the same issues from not knowing what to build, to building the wrong thing, being late with delivery, running over budget, to detrimental impact on dependent workstreams, or analysis paralysis we see with any other initiative in in the common — ‘less esoteric’ — software delivery realm.
But. Your pipeline is not what you think it is…
I have explained in another post that contrary to traditional opinion and intuition DevOps services and deliverables, including delivery pipelines and infrastructure are not hygiene, auxiliary or supporting, but that, in fact they must be seen as strategic capabilities and assets.
I have also outlined that our traditional view of who the stakeholders and users of DevOps, pieplines and infrastructure are is outdated and if not changed leads to sub-optimal decisions and will make us miss major strategic opportunities.
I have also illustrated that DevOps work is highly contextual: one size does not fit all.
DevOps and the resulting capabilities and assets can be strategic assets, highly context specific and must be user centric. Consequently, one-size does not fit all.
From tinkering to holistic product and service design
What prompted me to write this post is that I have worked with some of the most excellent DevOps engineers, but still it feels ‘tedious’, harder to get right than it should be. So if it is not a lack of (hard) skill, what is it?
I think we are having the wrong approach to DevOps.
Not in the sense that bringing Dev and Ops together is wrong, it is exactly the right thing. But in the sense that too often do we still see Ops simply supporting Dev in the delivery of software. Where in fact this should be a far more holistic activity, including the wider business.
What makes it so hard
Let me put it another way: Any reasonable organisation would pair even the most excellent team of software engineers with a product person. Of course you would. With pipelines and infrastructure however, we generally leave it to a minute group of ‘techies’ to define, design and implement the required assets.
I believe there are three reasons for this:
It’s complex
What makes hard to get this right is exactly the mix high context sensitivity, breadth of stakeholders, newness, complexity, breadth of available options, rapid pace of innovation (which also makes it such an opportunity) and strategic importance.
It’s new
Even more importantly, this being a highly specialised and new domain, many business do not know what they want or even require, and in practice we often find that communication breaks down between DevOps specialists and lay business people.
It’s technology
As with any technology role we also see a tendency to jump to solutions focused on a narrow horizon rather than taking an initial wider solution neutral approach.
It’ requires transformation
Quite often we also find a cultural challenge whereby the paradigm shift towards DevOps requires cultural transformation and mindset-shift: a shift to totally new ways of working but also towards a product view of pipeline and infrastructure.
Product Thinking and Service Design, the missing ingredients
While this won’t fix all, a major qualitative leap will made by adding product thinking to the mix, providing us with the right starting point:
We optimise value delivery by identifying real needs, understanding them in the wider context and satisfying them with fitting end2end solutions.
We achieve this by
positioning DevOps in the strategic organisational context and within that give it the attention it deserves
understanding the full set of users and stakeholders, specifically those beyond the direct sphere of impact
understanding their needs and expectations
forming hypotheses about best match between perceived need and solution option, providing a solution, testing and learning
designing holistic solutions considering the full end2end of people, process and technology
evolving solutions incrementally and evolve as circumstances change
So what we need to do is add Product Thinking into the mix. And voilà: we have not just any, but valuable output of our DevOps efforts, turning a tedious byproduct of IT into a strategic capability and asset.
In practice
Business focus
As operational driver or supporter DevOps need to be aligned with organisational goals, capabilities and constraints. Valuable DevOps process and assets recognise the business context and work towards business goals. In turn this means for many organisations that DevOps needs to be recognised as a part of, or even ‘the’, supply chain.
Product centric leadership
Appointing a Product Owner on client side and supporting this role with product-minded Business Analysts or DevOps lead who can instil product thinking and user centric practices in their team.
Champion human users
I would possibly go a step further and suggest that in some cases the addition of UX or CX designers to optimise workflows and tooling GUIs can be beneficial (but again, is often overlooked or deemed irrelevant as we are talking tools for developers. Which is a) not true and b) no reason to provide shitty user interfaces).
Use best practice tools
There is a whole raft of proven and well-understood tools from value proposition canvas, stakeholder onion, empathy maps to business model canvas or experience maps which we use in any other (well run) project. So we should be considering them in the context of DevOps too.
All this should come as no surprise really, as we have been working in exactly this manner with software delivery teams. Why then, would we work in any other way with other disciplines?
Secondary Benefits
While it is obvious to see how we achieve a much better fit of product to business need by adding product thinking and service design practices, I have also seen major benefits for the DevOps team themselves:
Urban myth suggests that technical people are nerds and want to do things their own way and don’t like to listen to users. But I find that this is not true: most of my colleagues (the good ones anyways) are highly interested in building the ‘right thing’.
And while they will be proactive and make the call based on gut-feel, intuition and experience if not better information is available, they are aware of limitations of this approach, which can easily lead to not only waste and rework, but also frustration.
By providing guidance and analysis we allow our DevOps teams to put their efforts into the most valuable areas and build assets and capabilities that actually delivery value, which makes for much happier teams.
Disclaimer: I am aware that DevOps is more than just a pipeline, more than infrastructure. I apologise for the gross simplification and possible seemingly distorted view, but in the interest of making a point in this article this simplification seemed helpful.
DevOps Leadership 2: Your Real Users
A holistic view of DevOps stakeholders and usersthedigitalbusinessanalyst.co.uk