Given the importance of taking an optimal approach for the type of work, it is important to understand what agile, lean, DevOps, and waterfall are and their history. People, historically, have spent very little time thinking about or improving how they do what they do. This is the second in a series of posts adapted from the book Sooner Safer Happier addressing these different frameworks.
What Is DevOps?
DevOps is a portmanteau that combines Development and Operations. DevOps focuses on breaking down the barriers between the teams responsible for developing a product and the teams responsible for deploying and operating the product. The term was coined by Patrick Debois when he created the DevOpsDays conference in Ghent, Belgium, in 2009. Agile in software development had alleviated the impediments to flow between customers, business analysts, developers, and testers; however, in many traditional organizations there was still a metaphorical brick wall between those building software and those running it, with a lack of shared understanding, accountability, or end-to-end flow.
Developers would build a product and then throw it over the wall at an increasing cadence, often with no notice or advice on supportability, for someone in a different role to deploy to production and support. IT Operations would tend to repetitively and manually fix issues in production without the Development team’s awareness such that many issues were rarely permanently addressed. The cost of IT Ops (“lights on”) would continue to rise, squeezing discretionary spending.
Typically IT build and IT run would not sit together, limiting collaboration and the ability to overhear (or even directly handle) repetitive support queries. Not surprisingly, getting closer to “you build it, you run it,” sitting people together in multidisciplinary teams, automating testing and deployment, and having a focus on failure demand, supportability, resilience, and observability all lead to better outcomes. Having to support your own product is a strong motivator to maintain high quality and supportability. The primary tribal identity is aligned to the customer, the value stream, and the product(s), not the job role. The team succeeds and learns together.
In The Unicorn Project, Gene Kim defines five ideals of DevOps:
- Locality and Simplicity: alleviate dependencies between teams and components.
- Focus, Flow, and Joy: the smooth flow of work that enables focus and joy.
- Improvement of Daily Work: continuously improve and pay down technical debt.
- Psychological Safety: a top predictor of team performance; enables improvement.
- Customer Focus: optimize for customer value, not for a role-based silo.
In my experience, DevOps can have a narrow IT Dev plus IT Ops meaning and a broader enterprise DevOps meaning. The broader meaning of DevOps is delivering Better Value Sooner Safer Happier. It is the application of better ways of working, end to end, to deliver business and customer value, leveraging many bodies of knowledge, including agile and lean. The biggest impediment to flow, to better outcomes, might be in behavioral norms, leadership, finance, HR, PMO, real estate, governance committees, and so on. If in your context DevOps is being used in the narrow meaning, be wary of local optimization. Once the weakest link in the chain is no longer the weakest link, little value will come from continuing to strengthen it. Identify the next weakest link, which could be project-based funding for example and alleviate that, before repeating forever!
Agile, Lean, DevOps, and other bodies of knowledge are all a means to an end, not the end itself. They are shared learning in human endeavor, which can be used in context to improve outcomes, to deliver Better Value Sooner Safer Happier.
In our next post in this series, we’ll examine the origins of the waterfall approach.
Leave a Reply