It's the Ranger4 #DevOpsFriday5 series and we have a brand new set of questions for your reading pleasure! Here to kick off the new batch is Gene Kim. He's DevOpstastic!
1) How do you think bi-modal IT complements or contradicts DevOps principles and practices?
Although some in the DevOps community have been quite vocal about their distaste for Gartner’s bi-modal IT model, I think it’s a fact of life for any technology leader who is responsible for hundreds or even thousands of applications—one simply cannot modernize every one of those applications at once. In this way, bi-modal IT offers a simple and useful lens to divide up the application portfolio.
However, this is by no means an excuse not to modernize. Jez Humble rightly points out that the entire “slower is safer” assumption is wrong—this was one of the decisive findings throughout the four years of the State of DevOps research that I’ve done with Jez Humble, Dr. Nicole Forsgren, and Puppet. We found that high performers deploy more frequently and also deliver more reliable service, achieving 60x higher change success rates and 168x faster MTTR. (Puppet's state of DevOps report)
This is clear from the experience reports coming out of the DevOps Enterprise Summit, which show that DevOps principles and patterns transcend technology and are as applicable to “systems of engagement” as they are to “systems of record,” such as forty year old COBOL applications running on mainframes, ERP systems running on SAP, CRM systems running on Siebel, etc.
2) How do you think an organisation can achieve end to end ideation to realisation? (Measuring the cost of a feature from inception to delivery and its value when operating in production)
Quite honestly, I find it extremely unlikely that there’s any actual value created if one doesn’t improve the end-to-end outcomes. This is probably why Lean techniques such as value stream mapping is so widely used, because it helps us document what work is performed in order to create value for our internal or external customer. For each step in the value stream, we can measure lead time (i.e., time required to deliver value to the customer) and “% complete/accurate” (i.e., what percentage is the output usable as-is?).
In general, the end-to-end process begins with the product owner, in the form of a customer request or formulation of a business hypothesis. Some time later, work will be accepted by Development, where features are then implemented in code and checked into our version control repository. Builds are then integrated, tested in a production-like environment, and finally deployed into production, where we (hopefully) create value for our customer.
Ultimately, any improvements we make in our value stream should result in improving customer outcomes, which hopefully includes reducing the lead time required to deliver customer value. (More on why I believe the lead time metric is so important is in question #5! :))
3) How do other frameworks or movements like Lean or Agile impact your ability to do better, faster, safer to drive up customer satisfaction and lower cost of service?
My personal definition of DevOps? It’s the collection of architecture, technical practices and cultural norms that enable the fast flow of work from Dev to Ops, while enabling world-class reliability, stability, and security. Specifically, they are also the outcomes and behaviors that result from applying the Lean principles to the technology value stream.
I believe that in many ways, DevOps represents the logical continuation of the Agile journey that began in 2001. Many of the well-known DevOps practices would emerge if we change the definition of "done." Not only must we have “potentially shippable code” at the end of each iteration, whatever is in trunk in version control must also be in a deployable state, and we must demonstrate features in production-like environments.
4) What are the key pieces of advice or encouragement you would give a devops change agent driving improvement?
One of my favorite books on “how to start transformation efforts” is The Other Side of Innovation: Solving the Execution Challenge—for me, it simultaneously explains why successful DevOps transformations suceeded, as well as why the failures failed.
The book was written by Dr. Vijay Govindarajan and Dr. Chris Trimble, both faculty members of Dartmouth College’s Tuck School of Business. Their studies describe how disruptive innovation efforts like DevOps can be achieved, despite the powerful forces that preserve status quo.
Some relevant takeaways include the need for a dedicated transformation team (as opposed to “maintain all your current responsibilities, but spend 20% of your time on this new DevOps thing”), selecting team members who are generalists, who have skills across a wide variety of domains, and who have longstanding and mutually respectful relationships with the rest of the organisation.
I’d also recommend watching all of the keynote talks from the DevOps Enterprise Summits in 2014 and 2015, which describe the successful transformations at organisations such as Target, Capital One, Ticketmaster, Raytheon, Macy’s, Blackboard, UK.gov, and many more.
5) What metrics really matter when you are doing devops?
I’ve had the privilege of being a part of the State of DevOps Report for four years—with Jez Humble, Dr. Nicole Forsgren and Puppet, we’ve collected survey results from over 25,000 IT professionals, with the goal of discovering the business value of adopting DevOps principles and practices, as well as understanding the practices that enable the best outcomes.
Here was a snapshot of the 2015 State of DevOps Report:
- Throughput metrics:
- Code and change deployments (30 times more frequent)
- Code and change deployment lead time (200 times faster)
- Reliability metrics:
- Production deployments (60 times higher change success rate)
- Mean time to restore service (168 time faster)
- Organisational performance metrics:
- Productivity, market share, and profitability goals (2 times more likely to exceed)
- Market capitalization growth (50% higher over three years)
Of these, the metric I like most is lead time—one of the most deeply held beliefs in the Lean community is that lead time is the most accurate predictor of quality, customer satisfaction, and even employee happiness. In our benchmarking work, we absolutely found this to be the case in the technology value stream as well.
So keep focusing on deployment lead times!
Gene Kim is a multiple award winning CTO, researcher and author. He was founder and CTO of Tripwire for 13 years. He has written three books, including “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” and the upcoming “DevOps Handbook.” Since 2014, he has been the organizer of the DevOps Enterprise Summit. In 2007, ComputerWorld added Gene to the “40 Innovative IT People Under The Age Of 40” list, and was given the Outstanding Alumnus Award by the Department of Computer Sciences at Purdue University for achievement and leadership in the profession.
Follow Gene:On Twitter
On his website
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.