This question is currently being hotly debated in boardrooms and the IT press around the world, and some people feel that the response will impact their future for years to come.
Recently, I had the pleasure of discussing the question with James Finister, Global IT Service Management (ITSM) Strategist for TCS in a BrightTalk webinar called: Is DevOps REALLY the new answer to business technology value? And this blog highlights the questions we posed and our key discussion points.
We encourage you to become part of the conversation by sharing your thoughts in the comments section below.
Question 1: DevOps has no agreed definition, so what do we feel DevOps is about?
Historically the challenge has been to get the project management office (PMO), Development, ITSM, IT Operations, and suppliers to all talk and play nicely together.
DevOps is challenging us to think about how we collaborate to create something that helps solve business problems. DevOps is as much a cultural change as it is technological.
Question 2: Does ITSM still have a role in DevOps?
Our view on this is best articulated by Gene Kim, one of the key voices of DevOps, who states that:
“It is my firm belief that ITSM and the DevOps movement are not at odds. Quite to the contrary, they’re a perfect cultural match.”
Question 3: Does ITSM need to change in light of DevOps?
ITSM does not need to change but certainly the way organizations think about why they want to use ITSM – or Agile or any of the movements – needs to change.
They need to constantly focus on how these movements can help them create, deliver, and support their goals when technology is required.
Question 4: How then do these elements, these movements, come together?
DevOps proudly borrows elements of other movements such as Agile and LEAN. “Their overlap is DevOps” is one view. Another could be that DevOps is becoming the umbrella which all the others support.
Whatever you decide, you need to not look at them separately (i.e. more silos) and instead need to decide how these practices will aid you across the lifecycle, in decision-making, in supplier management, and in tool selection and use.
Question 5: We keep going back to the cultural aspect (of DevOps and ITSM) but at the moment this is still very much about the IT perspective, isn’t it?
This is changing and organizations are now talking about BizDevOps or reminding IT they are part of the organization and to stop saying “Us and Them.” A good example is based on a conversation with a delegate at last year’s DevOps Enterprise London event – when asked what his job was, he answered DevOps Engineer.
When asked to explain more he gave the perfect response: I create the processes that allow people in my media organization to use technology in the best way possible. He did not discuss the tools, he only talked about how technology improved his organization.
Question 6: How do you amalgamate all of the THINKING movements?
They all offer different ways to look at DevOps. This is not “out with the old and in with the new,” but that DevOps builds upon these movements.
CX (customer experience) thinking for instance is absolutely critical to developing a DevOps strategy, as we need to understand how what we are doing is impacting the customer.
These are all very powerful techniques that we need to use as opposed to having a team of LEAN or ITSM or DevOps people. Having these teams simply leads to more silos and these techniques should help us to see a different way of thinking about how to best use technology – led by senior management in a top-down manner.
Question 7: What is “value” (and this is a BIG question)?
Real world value aspects include (and this is not a full list):
- Reduced cost of sales and retaining customers
- Improving customer satisfaction, profit, billing cycles, and employee engagement
We have probably all sat in presentations where people go on and on about how they can introduce value but then, at the end, no one can really express it.
“A hypothesis held by the organization’s leadership as to what will best accomplish the organization’s ultimate goals or desired outcomes.”
James and I like the word hypothesis, as this clearly shows that the business does not have all the answers and that value is a “best guess” which changes over time. Furthermore, this stresses that this is a business goal/value and not IT’s.
Question 8: Is DevOps still too Dev focused? And how is this impacting return of value?
It’s important to think through the lifecycle and never forget the support aspect. We have to deliver a usable service and product, not just a completed project.
We also blame the culture that tools can solve everything. A big issue that’s beginning to be resolved is the dichotomy of tools where Dev tools are closely linked to business problems, while IT Ops/ITSM tools interface to technology.
The way you want to work, who does what when and how and even the use of suppliers (service integration and management, SIAM) has to be discussed more broadly to be successful with DevOps. And ITSM teams need to be at the forefront of that discussion.
Question 9: Do you think that value changes along the attraction curve?
The “attraction lifecycle” based on “diffusion of innovation theory” means that we need to attract supporters before we try to change the organization.
Too many times we write business cases for the CEO without firm proof of benefit. Thinking about how DevOps can provide value and getting people interested and showing that this works, will generate focus, energy, and funding for further introduction. It takes thought and trial/error to create that strategy to move along the curve and maintain senior management support.
It’s interesting to see what happens if you shift left from where “all are attracted” back to those early adopters. For example, use the service desk to capture knowledge on the products/service liked versus those that break. Work back to the original request and you can better see who may be your best supported innovator, even if not an obvious choice.
Conclusion: DevOps introduction strategy including governance, culture, voice of the customer, metrics, constraints, adoption, and tools
The points below are not a step-by-step guide but rather things to consider along the journey:
- Governance is key to helping organizations to set a different culture, see constraints, have metrics that matter, and tools that help.
- No big bang approaches and no forcing the issue of “being DevOps” in two years. We have to stop this thinking, no matter what movement we are introducing and focus on why we are going to introduce this change of behavior and capability. DevOps is about leadership changing the way they think and coach change.
Forrester analyst Rob Stroud suggests that DevOps allows macro governance: letting people deliver against just enough governance at a faster pace but still within agreed constraints. Examples are getting rid of meetings and replacing them with better automated testing, and having metrics that matter to the business – such as right first time, quality, safety, cost, employee satisfaction, and customer delight.
We should learn from previous efforts. I see organizations that struggle with Waterfall and then move to Agile but culturally they can’t cope with either so attempting to introduce DevOps is not possible. Management needs to be upskilled or coached to help make this transition effectively.
Theory of Constraints and LEAN thinking also has to be part of any DevOps practical introduction, to help see the true bottlenecks and then ascertain how to use them or remove them to the benefit of the team, business, process, and customers.
Both James and I believe in the value of tools but only after we know how we really want to use them. Looking at tools first is not the right way, and can be harmful and expensive in the long run.
Please join in the conversation: Is DevOps of business value? And if you don’t introduce DevOps into your organization, will you survive?