DevOps is a hype topic, and its promises are legendary: integrate Dev and Ops so that nothing breaks in production, achieve fully automated testing and deployment, trigger 150,000 deployments per day (with out breaking things) and achieve light-speed innovation. The technology is also there: metrics processing, automation and machine learning. But, what about the people? How well are we handling the organizational change needed to implement DevOs?
Until recently, DevOps didn’t have a hard and fast body of knowledge like ITIL or other methods. Rather, it emerged from several strands of thinking: Agile, Lean, continuous delivery etc./1/ The publication of “the Phoenix Project” (2013) and the “DevOps Handbook” (late 2016) have resolved that problem./2/ In brief, DevOps means integrating development and operations to achieve highly agile, but robust IT organization and infrastructure.
To get there, Kim and friends center DevOps around the 3 Ways of flow, feedback and continuous improvement, thus drawing on well-proven methods from Lean Manufacturing movement and the Theory of Constraints./3/ Flow means creating a continuous flow of work that is passed from development into testing and into production. Feedback entails creating feedback loops for the team and the technology, so that we know where we are, what is working, what is failing etc. This knowledge thus fuels continuous improvement, both in the architecture and in the organization.
This vision gets every techy exited. But, what about the people? How do we achieve the transformation within the organization? Fortunately, DevOps supplies some answers./4/
Flow, value and speed: Teams should be optimized to satisfy market demand quickly, not for cost. Lean manufacturing discovered decades years ago that only a working, finished, delivered product actually added value. In the IT, working code and systems that users use is the fundamental measure of value. Thus, all aspects of workflow are optimized for getting the through development and testing to a productive system. Automation is key, but more importantly, the teams must understand where value is created. It is not created in any one step, but in the working final product. The product team’s job is to work together for that one goal.
Cross-functional teams: in DevOps, various organizational structures can perform equally well, as long as sufficient trust exists and a common focus on providing “value for the customer” guides the work. But, everyone in a product or service team should become a “T-shaped” generalist, with high expertise in one are, but also broad knowledge in others. Such persons understand the implications and interconnections of their work with that of their colleagues. Furthermore, such teams can more easily absorb variances in workload, thereby gaining flexibility while holding throughput high.
Everyone owns operative quality: teams become together responsible for the product or service. Thus, testing, security and operations are everyone’s responsibility. Coupled with the new view on value, goals become shared, as is the pain when something fails.
Continuous improvement: nurtured by feedback loops, a continuous improvement mindset must be internalized by everyone. As DevOps intends it, this approach goes further than the usual platitudes of creating a learning organization. Rather, everyone, as a T-shape generalist focused on value creation, sees the full picture of how their work contributes. Thus, solving problems and correcting failures rises to the system level. I don’t just root out bugs in my code. Rather, I create ways so we can find, indeed prevent, errors systematically. Standardization, automated testing and continuous delivery are the operative buzz words. At the core, it entails shift in mindset by each member of the team to strive always to improve whole system, in otherwords to improve us and our ways of working.
/1/ The internet literature on DevOps is fast. One place to start is John Willis’s summary. In its earliest incarnation, DevOps was called VisibleOps. At the time, it looked a lot like a “Lean ITIL” See Jan Fischbach’s discussion in these pages here. DevOps has grown to include a lot more, especially aspects of continuous delivery and lean startup.
/2/ Gene Kim et al., The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Portland, OR: IT Revolution Press, 2013); Gene Kim et al., The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations (Portland, OR: IT Revolution Press, LLC, 2016). Also see Jan’s review of “the Phoenix Project” in English and German.
/3/ Frequently cited as the starting point on Lean is James P. Womack et al., The Machine That Changed the World, (New York, NY: Free Press, 2007). I personally find most valuable Masaaki Imai, Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy, Second Ed. (New York: McGraw Hill, 2012). On Theory of Constraints, see Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement, 2nd rev. ed (Great Barrington, MA: North River Press, 1992).
/4/ The following paragraphs draw from Kim et al. “The DevOps Handbook”.
Until recently, DevOps didn’t have a hard and fast body of knowledge like ITIL or other methods. Rather, it emerged from several strands of thinking: Agile, Lean, continuous delivery etc./1/ The publication of “the Phoenix Project” (2013) and the “DevOps Handbook” (late 2016) have resolved that problem./2/ In brief, DevOps means integrating development and operations to achieve highly agile, but robust IT organization and infrastructure.
To get there, Kim and friends center DevOps around the 3 Ways of flow, feedback and continuous improvement, thus drawing on well-proven methods from Lean Manufacturing movement and the Theory of Constraints./3/ Flow means creating a continuous flow of work that is passed from development into testing and into production. Feedback entails creating feedback loops for the team and the technology, so that we know where we are, what is working, what is failing etc. This knowledge thus fuels continuous improvement, both in the architecture and in the organization.
What does that mean for the team?
So, with DevOps we create feedback loops through out the system. Telemetry is built into every component, and the data flows to state-of-the-art correlation engines, giving us feedback on performance, security, availibility etc. Changes, kept small, are tested rigorously and released on the basis of the generated knowledge. With automation, we achieve all this efficiently. Over time, components become more and more robust until virtually all architectural weaknesses have been weeded out. It’s the Toyota Andon Cord in binary and gigahertz.This vision gets every techy exited. But, what about the people? How do we achieve the transformation within the organization? Fortunately, DevOps supplies some answers./4/
Flow, value and speed: Teams should be optimized to satisfy market demand quickly, not for cost. Lean manufacturing discovered decades years ago that only a working, finished, delivered product actually added value. In the IT, working code and systems that users use is the fundamental measure of value. Thus, all aspects of workflow are optimized for getting the through development and testing to a productive system. Automation is key, but more importantly, the teams must understand where value is created. It is not created in any one step, but in the working final product. The product team’s job is to work together for that one goal.
Cross-functional teams: in DevOps, various organizational structures can perform equally well, as long as sufficient trust exists and a common focus on providing “value for the customer” guides the work. But, everyone in a product or service team should become a “T-shaped” generalist, with high expertise in one are, but also broad knowledge in others. Such persons understand the implications and interconnections of their work with that of their colleagues. Furthermore, such teams can more easily absorb variances in workload, thereby gaining flexibility while holding throughput high.
Everyone owns operative quality: teams become together responsible for the product or service. Thus, testing, security and operations are everyone’s responsibility. Coupled with the new view on value, goals become shared, as is the pain when something fails.
Continuous improvement: nurtured by feedback loops, a continuous improvement mindset must be internalized by everyone. As DevOps intends it, this approach goes further than the usual platitudes of creating a learning organization. Rather, everyone, as a T-shape generalist focused on value creation, sees the full picture of how their work contributes. Thus, solving problems and correcting failures rises to the system level. I don’t just root out bugs in my code. Rather, I create ways so we can find, indeed prevent, errors systematically. Standardization, automated testing and continuous delivery are the operative buzz words. At the core, it entails shift in mindset by each member of the team to strive always to improve whole system, in otherwords to improve us and our ways of working.
/1/ The internet literature on DevOps is fast. One place to start is John Willis’s summary. In its earliest incarnation, DevOps was called VisibleOps. At the time, it looked a lot like a “Lean ITIL” See Jan Fischbach’s discussion in these pages here. DevOps has grown to include a lot more, especially aspects of continuous delivery and lean startup.
/2/ Gene Kim et al., The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win (Portland, OR: IT Revolution Press, 2013); Gene Kim et al., The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations (Portland, OR: IT Revolution Press, LLC, 2016). Also see Jan’s review of “the Phoenix Project” in English and German.
/3/ Frequently cited as the starting point on Lean is James P. Womack et al., The Machine That Changed the World, (New York, NY: Free Press, 2007). I personally find most valuable Masaaki Imai, Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy, Second Ed. (New York: McGraw Hill, 2012). On Theory of Constraints, see Eliyahu M. Goldratt, The Goal: A Process of Ongoing Improvement, 2nd rev. ed (Great Barrington, MA: North River Press, 1992).
/4/ The following paragraphs draw from Kim et al. “The DevOps Handbook”.
Kommentare
Kommentar veröffentlichen