0 saved
12.9K views
Development and operations teams both care about their customers. However, while dev teams strive for rapid product improvements, ops teams are typically focused on delivering a stable, reliable customer experience — often putting the teams at odds.
Embracing a DevOps Mindset involves delivering greater customer value by better integrating the work of development and operations teams. It incorporates a loose set of principles that encourages all teams to own the end-to-end process by leveraging greater collaboration, shared tools, automation, continuous monitoring, and continuous improvement.
YES, IT’S ABOUT DESTROYING THOSE DAMN SILOS.
DevOps has become the standard practice of big tech and startups alike, though it remains a broad movement rather than a strictly defined approach. That said, implementing DevOps tends to begin with culture, leverages technology, and includes working to increase:
-
Collaboration and breaking down of silos: with cross-functional teams and greater inter-team transparency. This is in part cultural but will likely incorporate processes and team structure for improved collaboration.
-
Automation & streamlining: including using standardised tools between teams, and automating processes.
-
Continuous delivery: with small, gradual changes rather than large, infrequent builds — thus embracing continuous integration and deployment for ongoing and continuous improvement.
-
Accepting failure as normal: providing the systems and culture to address inevitable problems quickly.
-
Embed and amplify feedback loops: measuring, monitoring, and logging results to provide continuous feedback. This also includes incremental experiments.
-
Systems thinking and taking end-to-end responsibility: challenging the idea of ‘throwing a build over the wall’ and moving towards habitually 'viewing the whole' and taking responsibility for the entire lifecycle.
DEVOPS AND AGILE
On a simplistic level, whereas Agile Methodology sets out to deliver greater value by iterating and supporting adaption, DevOps sets out to deliver greater value by better managing and combining the end-to-end process from delivery to operations.
Rather than an alternative to Agile, DevOps is generally implemented as a means to extend Agile beyond traditional software and dev teams — See Origins below for more.
'EVERYTHING-OPS'… REALLY?
Like Agile, DevOps was originally created by and for engineering teams and is already having ramifications on broader business practice.
Practitioners point out that DevOps is not just about development and operations teams but often involves management, testers, QA, security, data, and other domains. Indeed, it’s tending to spawn a range of related terms:
-
SecOps/ DevSecOps: which involves integrating security as central to the lifecycle rather than an afterthought.
-
BizOps/ BizDevOps: aims to connect business operations and technology, development, and operations for greater inter-department transparency.
-
DataOps/ DataDevOps: integrating data engineering and analytics into the DevOps approach.
-
ChangeOps: The State of DevOps Report 2020 goes into considerable detail about the need to integrate a DevOps approach with change management, see the In Practice section below for more.
In addition, there’s WinOps, which is Microsoft’s brand of DevOps and Site Reliability Engineering (SRE), which was developed by Google in 2003, predating DevOps and generally viewed as a specific application of its principles.
While there's more that could be said about the tech version of DevOps (such as Microservices, tech tools etc), we've focused on the more transferable elements, especially in the Actionable Takeaways below.
IN YOUR LATTICEWORK.
We’ve already talked about how a DevOps Mindset links to Agile Methodologies, including Scrum and Kanban, and it's also in part inspired by Lean Thinking.
Most practitioners stress that the cultural change and team dynamics that underpin a DevOps Mindset will require Psychological Safety, including practices such as ‘blameless postmortems.’ Cross-functional collaboration at the heart of DevOps will also benefit from T-Shaped People and can be informed by the 5 Stages of Teaming.
Not in an Agile organisation? Not a developer? Fortunately, there are still some general principles that can be gleaned and broadly applied as part of a DevOps Mindset:
- Map teams across the end-to-end value chain - then engage them early and often.
Choose something that you're working on and map out the end-to-end value chain. Who will be touching it, supporting it, maintaining it, and receiving feedback on it as it reaches customers or end-users? Raise your vision beyond your silo, and ensure you know everyone else involved in the process, then engage with them to gain new insights and perspectives.
- Increase transparency and knowledge sharing.
Consider how your team’s work is being viewed by the rest of the organisation. How can you provide greater transparency about your work in progress, not just your work product? This might include documentation, visual representations of your work and progress, internal blogs, showcases, and cross-functional workshops.
- Standardise tools.
When choosing new tools for your team or division, consider what other teams are using. Standardising tools provides opportunities for greater streamlining and connections.
- Encourage a customer-centric and end-to-end approach.
Challenge yourself and your team to picture where your work fits into delivering value for customers. Rather than ticking the box on your defined deliverable, consider how it adds to a bigger offering — and will ultimately fail unless it integrates effectively. Embrace the mindset of ‘you build it, you run it’ to avoid the ‘throw it over the wall and forget it’ alternative.
- Monitor and establish instant feedback loops.
Establish metrics that matter across the entire process, especially as your output meets the end-user. Consider how to maintain and gain greater feedback with better processes and automatic feedback loops that go right to the development team.
- Accept failures, and learn.
Strive for a Psychologically Safe environment (follow the link for further tips), including organising blame-free retrospective meetings, and providing the opportunity and space for your and other teams to call out issues early and immediately.
- Focus on culture, use technology and process to support the change.
A DevOps Mindset is largely a cultural shift that challenges the ‘them vs us’ nature of internal teams. Consider how technology can support this journey but don’t rely on tech quick fixes.
The main limitation relating to DevOps is the one you’d likely expect: Silos are hard to challenge and break down.
A large, scaling enterprise needs divisions and teams to get stuff done, and alignment between those growing teams is hard to maintain. This will play out on a cultural level, of teams not wanting to ‘slow down’ to engage with another group they see as an optional extra; to tech issues, for example with challenges to integrate and standardise tools across domains.
In this article on DZone, Jim Bird notes that DevOps is shrinking the scale and focus of development, explaining: “Because Devops brings developers much closer to production, operational risks become more important than project risks, and operational metrics become more important than project metrics. System uptime and cycle time to production replace Earned Value or velocity. The stress of hitting deadlines is replaced by the stress of firefighting in production and being on call.”
This is less of a criticism, rather an exploration of implications of ‘Ops’ being injected into Devs leading to shifts in job roles and broader goals.
ChangeOps – combining Change Management and DevOps
As outlined in the overview, DevOps has already started to catch on in some sectors including DevSecOps, incorporating security, and FinOps, incorporating a view of people, process and technology in the context of financial operations. There have been other suggestions of BizDevOps to encompass a range of departments from Sales to HR. For now, let’s dive into Change Management.
The State of DevOps Report 2020 goes to great lengths to advocate applying DevOps principles to Change Management, which in turn is identified as a common bottleneck to releasing enterprise-wide software. Their recommended DevOps approach to Change Management, dare we say ChangeOps, includes:
-
Breaking down silos, building empathy and iterating. Engaging with change, release, audit, compliance and other teams to understand and empathise with their needs.
-
Encourage a process of bounded experiments and iterating as more is learnt.
-
Create feedback loops. Ensuring that affected groups have a voice and their responses can be tracked.
-
Measure the impact. Identifying key metrics upfront and providing transparency on how these metrics are tracking while striving for continuous improvement.
d
Some argue that DevOps developed because developers built code in a defined production environment before throwing it over to operations without an understanding of how it would work ‘in the wild’.
Others suggest that DevOps in part arose from a tendency of Agile organisations to silo Agile practice in development teams, leaving operation teams and broader business still running traditional waterfall approaches. Either way, DevOps will often involve extending a consistent Agile approach across the business.
The foundations for DevOps began early in the 2000s, with Google working (secretly at the time) on their SRE approach. Amazon CTE Werner Vogels made these comments in 2006:
“Giving developers operational responsibilities has greatly enhanced the quality of the services, both from a customer and a technology point of view. The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software. It also brings them into day-to-day contact with the customer. This customer feedback loop is essential for improving the quality of the service.”
While it was part of a broader movement, the actual word 'DevOps' was first used by Patrick Debois by combining ‘development’ and ‘operations’. Debois explained:
“I think what year was it – 2008. I was working with agile people in development group and doing support. I wanted to be as flexible and as fast as them in infrastructure. I started exploring the idea of agile infrastructure. In 2009, I got the idea of organizing the first DevOps Days, because clearly, I wanted to have development and operations folks work together. I guess I was kind of patient zero by creating first event, and by accident coining the term DevOps with the first event. From there, it just started all over the world.”
In terms of additional resources, Puppet’s annual State of DevOps Report 2020 is a wonderful resource for learning more about DevOps as a movement, including current trends.
My Notes
Oops, That’s Members’ Only!
Fortunately, it only costs US$5/month to Join ModelThinkers and access everything so that you can rapidly discover, learn, and apply the world’s most powerful ideas.
ModelThinkers membership at a glance:
“Yeah, we hate pop ups too. But we wanted to let you know that, with ModelThinkers, we’re making it easier for you to adapt, innovate and create value. We hope you’ll join us and the growing community of ModelThinkers today.”
You Might Also Like:
- Actionable summaries of the world's most powerful ideas.
Subscribe now and download this practical guide to transform your thinking, plus recieve one short, powerful and actionable idea in your inbox each month.