BrightTALK recently introduced a new webinar concept – what they’re calling an “Ask the Expert” series – to discuss a variety of popular topics such as cyber reliance, machine learning, IT service management (ITSM), blockchain, etc. And they asked me to kick it off with a conversation on DevOps and ITSM.

The “twist,” and unique selling point (USP), of these new-style webinars is that there are no slides, instead the presenter (me in this instance) simply responds to any number of questions asked by webinar participants (circa 200 people in my session) during the 45-minute event. The main challenge here being that it proved impossible to address all of the submitted questions in just the one session, and thus this article aims to respond to those questions that I was unable to cover during the live event.

Below you’ll find my responses to all of the unanswered questions pertaining to DevOps, ITSM, and leadership. In addition, I’ve also covered the questions that I did get a chance to answer, in case you don’t have time to watch the full webinar recording.

1. In relation to traditional project management process groups (initiate/plan/execute/monitor and control/closing), how does DevOps differ in the integration of these critical phases?

DevOps and ITSM embrace these phases and ensure that delivery is as expected across the entire value stream.

We want to get fast flow with feedback as soon as possible, such that what’s deployed is what was asked for, ensuring benefits for the requestor.

We also look forward to improving not only what we created, but the process flow such that the next request can be performed better, faster, and perhaps with less cost or resources.

Value stream mapping, key performance indicators (KPIs) across the stream, Kanban views of work, team collaboration, and constantly obtaining customer feedback are all part of both approaches.

2. Can an organization that has still not matured itself in the concepts of ITIL/ITSM enough, move into, or adopt, DevOps and do well?

As I mention at the start of the recording, ITSM and DevOps are both blends of a variety of technology practices.

We need a strategy to design against and, once satisfied, we transition that product or software or process into operational use with the goal of continuously improving it.

Take ITIL value streams such as the resolution of incidents – we need to agree the strategy of addressing these and, once they occur, get them resolved as quickly and correctly as possible. The DevOps Handbook has pages of how ITSM and DevOps co-exist and you can continue to mature your organization by adopting DevOps practices.

3. Is it possible to apply a DevOps approach within an outsourced model? And, if it’s possible, what are the success criteria to achieve this?

What really is an outsourced model? Is it not a team of people working with your team to ensure that technology is being managed correctly? DevOps simply asks that everyone appreciates the roles and responsibilities of who is supposed to do what and when, and agrees the why and metrics of each step.

Service integration and management (SIAM) is an excellent example of this, as well as ITSM supplier management. DevOps lets teams communicate over common tools and processes and work together to help the customer organization get great technology.

Success criteria are the same as if internal: mean time to resolution (MTTR), cost, quality, people skills, customer satisfaction, and mean time to maintenance (MTTM).

4. How can continuous integration and deployment be accomplished on cloud-based systems, such as SAP SuccessFactors for example?

DevOps loves cloud! Where else can you quickly create or scale your production environments for people to develop and test before letting things go live? While I do not know SAP; Virtual Clarity does help customers take advantage of deployment, development, support, and management capabilities of virtual, hybrid, or public cloud. This webinar helps explain further.

5. How can DevOps be used to bridge the gap between developers and post-go-live support? It’s a common challenge to find operations lagging behind development.

This is the heart of DevOps: collaboration. No laggards!

The problem is that in non-DevOps or mature ITSM organizations there are a series of silos. Each silo imposes their own controls over the work to accept, which slows things down or makes discussions difficult.

DevOps encourages teams to work together on the support of a product, application, or service. With the service desk you create the way you will respond to incidents and requests, and if you can automate this, then you can add to the self-help portal:

  • “Infrastructure, we need something for our software to run on so please get us IaaS or Cloud-based services”
  • “Security, we want to ensure that what we deploy is safe.”

All of this and more has to happen daily, so the teams need to self-organize and work with common tools. Most importantly they need common KPIs: we both get paid to get things deployed and keep things working. Usually Dev has a different set of objectives than Ops. Change that culture and watch the teams mature.

6. Are there any similarities between CD&CI and DevOps?

Continuous integration (CI), continuous delivery (CD), and continuous deployment (CD+) are all part of DevOps.

Creating development environments that resemble production and then implementing processes and tools to flow that development to go-live as quickly as possible is what makes DevOps fun. We also automate the controls, governance, and documentation of what has been deployed and how to support it. You can learn more about this in the DevOps Handbook mentioned above or read the series at IT Revolution.

7. You mentioned the term “Agile Service Management,” which I assume refers to adapting ITSM frameworks such as ITIL to our current dynamic IT environment with Agile, DevOps, and cloud-type technology… can you recommend a book, forum, or author that covers this “Agile Service Management” approach please?

Firstly, you can read my blog. Next you can go to the DevOps Institute to discover more about Agile ITSM.

The main point of blending these two practices lies in the premise that the best place to create a process is where the work is being performed. Rather than create a heavy process with a large policy and Visio diagram, treat the process and the process steps like a product. Value stream map the process and iteratively improve the steps via the introduction of automation.

8. Do you agree that the (central) IT helpdesk may still be needed to address end-user questions or do you propose another solution? How do you keep the information up-to-date given the very fast changes, and still enable routing and answering questions?

I think that people will always look for people to help them. The question is: why are people calling the IT helpdesk? They aren’t paid to do so and it’s a waste of time.

So, can technology (such as Alexa or ChatWeb) help people? Can artificial intelligence (AI) help provide solutions and even execute them? How smart can your help/service desk become? This is the next challenge.

9. How do you handle user-reported issues with an unclear root cause that may require multiple DevOps teams?

This challenge has existed for a long time and ITSM provides great practices to look at in terms of escalation.

However, the thing that many get incorrect is who owns the incident. Instead, the challenge should be viewed as who owns: coordinating these teams together; finding a counter-measure; testing it; deploying it; and then ensuring it has resolved the issue? This owner now needs to let the teams add a piece of work, on understanding how to not let that issue occur again, to their backlog.

To help, incident logging, ChatOps, value stream and process mapping, wikis, and monitoring and alerting are all tools to consider but you need a strong RACI (responsible-accountable-consulted-informed) matrix first.

10. Adopting DevOps surely puts more pressure on IT security due to the speed of deployment? How do we best manage this please?

Adopting DevOps places more pressure on all aspects of the technology lifecycle. Agreeing change, deploying, fixing, and more.

Security needs to be embedded in the process of creation and testing as early and as often as possible. Tools today like the Sonatype suite or SauceLabs can help get you started.

11. Can DevOps practices be effectively implemented and utilized in smaller organizations with perhaps a lower level of software deployments? In essence, can ITSM still benefit from applying this approach in such environments?

DevOps is NOT only about software deployment.

DevOps is about the culture of using and benefitting from technology in your organization. How do people use it to help customers or themselves? Based on this, leaders need to get the right stuff to the right people at the right time and ensure this can be changed easily as business opportunities change (including regulatory and Brexit impacts).

ITSM is an integral part of DevOps. They’re not separate. DevOps just helps you ask more questions and focus on any waste or improvements you need to make.

12. What’s your view on Agile and DevOps? Does a DevOps team definitely need to use the Agile methodology to operate?

DevOps encourages speed and quality while mitigating risk. It sounds like Agile!

Small chunks of something are deployed when agreed (product, service, application, process). In which case you need to agree that thing and get the team to deliver it right first time. DevOps is a great blend of Agile and ITSM plus other methodologies.

13. In my opinion, DevOps delivers the products and ITSM serves as “after support,” or are you saying wrap DevOps in ITSM?

Yes, wrap it.

Don’t silo the methods, merge them. Then you can deploy fast and safe and always be ready to support. My “support” team is the team that deployed, and they have the skills needed to perform their role.

14. In your view, who are the top software industry leaders that are leading DevOps technology today?

This list is a great start of DevOps influencers.

15. How do you tidy these interactions between ITSM, DevOps, Lean, and Agile to align with business objectives?

I use a Lean concept called Hoshin Kanri.

Agree the strategy, get some key measure of success, and let each team create measures to match. Now flow the work ensuring that success is met or if blocked, then people can swarm to unblock the effort.

It’s not easy and means leaders, staff, and suppliers all need to change their behavior and continuously look as to how technology is being used and managed.

16. What recommendations/advice would you give to managed service providers (MSPs) in terms of helping their clients achieve higher maturity levels of DevOps and ITSM?

I would flip the question: what advice would I give to people who depend on MSPs? They need to be treated as part of the team. They need to share common data. They need to have common processes. They need to collapse the change, fix, and improve lifecycles.

Teams and leadership need constant involvement with agreed KPIs (not service hammers) that allows the team to own their work. SIAM is a great DevOps model.

17. How would you factor in enterprise architecture and solution architecture into this approach?

Why do you separate them? Aren’t they the same? Aren’t they designing the rules of consistency that allow the creation, introduction, and management of technology? They create the high-level and quickly respond to improve.

18. What was the name of the author who recommends redefining/dismantling internal organization IT functions?

Mark Schwartz! And I did not say he recommends this but instead he challenges all technology leaders to think about how they lead and support organizations and teams, and use suppliers in their daily role.

19. DevOps is about continuous integration and continuous deployment, how can an IT organization that leverages an ITIL change process get into a DevOps model? Because the ITIL change process is more focused on risks evaluation and having documented procedures for change implementation, whereas integrating DevOps seems to be risky as there are possibilities that testing is not done properly. How do organizations mitigate such risks?

Change is the process of approval. How does it know to say yes or no? Testing! Testing is the process of risk control. DevOps or ITSM love tests. Run them all the time in your CI, CD, and CD+ environment lifecycles. But look at what happens as things move across the lifecycle and use this knowledge to improve your testing. DevOps encourages flow, feedback, and learning. Learn from your tests on how to control risks and improve quality and performance.

20. What kind of organizational culture change is required to transition the IT team to being DevOps driven?

Leaders must change and then help others to DevOps (or ITSM) themselves. Books like Lean Enterprise, The DevOps Adoption Handbook, or The Phoenix Project can help begin the journey but once started, don’t stop. Keep going!

21. My understanding on DevOps – in a fast changing Retail market, is that we need to keep up the time to market, hence we automate the process. Is this right?

Yes, where it makes sense. The question is always going to be how to remain competitive and cost effective. DevOps helps address this flow.

22. What’s the biggest challenge for a leader of an organization’s ITSM practice related to staffing?

First the leader has to learn their role or skills. The leader must adapt to becoming a coach and letting teams gain the authority to determine the best way to work and deliver. Management 3.0 is an excellent book as well as VeriSM.

That’s all folks…

So, there you have it, all of the pressing questions that webinar attendees wanted to know about ITSM and DevOps answered. Plus you can access the recording of my session here.

If you have any other questions that are not covered here, please post them in the comments and I’ll address them too.

Finally, if you like the format of this new BrightTALK webinar series, you may be interested to know that they have other sessions coming up on the topics of:

  • Cryptocurrencies
  • Machine Learning and Deep Learning
  • Cybercrime
  • Blockchain
  • Managing Change in Cloud-Based Systems
  • Behavioral Finance
  • Licensing as a Service

You can sign up for these here. And remember, all BrightTALK sessions are recorded so you can also access the recordings at any time, here.

Let’s face it, technology is expensive. No matter the type or size of your organization, technology will most likely be one of its top three expenses along with people and facilities.

Technology financial management – getting maximum value out of your IT investments – isn’t easy, but by changing the way in which we think about IT budgeting and funding we can help our teams, suppliers, and customers to deliver better, faster, safer, and more cost-effective IT and business services.

Budgeting 101

Most corporate budgets follow an annual cycle something like this:

  • Somewhere between July and October, you will respond to a budget email stating what you want – budget-wise – for next year
  • Somewhere between September and December, you will discover that your request was fulfilled minus x% (although hearing it after the next financial year has started is not unheard of)
  • In January or February, you might receive notice that you’re over budget, because December bills weren’t accrued properly and have now been attributed to the new fiscal year
  • In late October (and maybe earlier), you will receive notice that you’re under budget – so please “use it or lose it”

Then corporate budgets are split between capital expenses (CapEx) and operating expenses (OpEx), with CapEx for new or significant, high-cost changes, and OpEx for the daily running of your business.

Common Budgeting Pains

There are numerous age-old potential issues for those involved in IT budgeting, these include that:

  • The planning process is slow and often doesn’t allow for changes to be introduced with agility to meet changing circumstances
  • Budgets are set and therefore managers feel constrained; especially as their bonuses are probably linked to their ability to stay in budget but not set against the value they deliver
  • Budgets don’t necessarily underpin the decision-making process and thus don’t act as a guide instead of a constraint

Then others that are more recent:

  • Many companies are now use Agile techniques (Scrum) and expect teams to deliver something every two weeks against a budget that is set for a 13-15-month plan and has no link whatsoever to the two-week cycle
  • Agile product owners are forced to fund work against annual budgets, or risk losing that money, rather than looking at how to deliver value and therefore continue to obtain funding based on that work
  • The outcomes of forcing antiquated budgeting processes onto Agile teams discourages transparency and adversely affects morale

Is it Time for Agile Budgeting (and Funding)?

What if we decentralized the management of money from the granting of money? What if we used the practices of Agile to create an iterative budget? Such that:

  • We would agree an annual plan (budget) which underpinned the 3-5 year plan
  • We would map Epics against the budgets
  • We would breakdown the work into use cases in collaboration with the product owner, teams, and where possible customer – showing cost and expected value
  • All breakdowns would be in the product backlog
  • Tools would show the amount of time for a piece of work and also the cost and expected value to help in the grooming and prioritizing of work
  • Work would be assessed against value and cost as well as other factors during the retrospective
  • Additional funds would be granted as value was redeemed
  • Legacy or technical debt activities performed as part of a sprint would contribute to the funds available for a product
  • Reporting, monitoring, and alerting would be integrated into the financial tools and processes of the organization
  • Quarterly reviews of the budget and subsequent decisions would enable further funding

But this isn’t just a change in the way we budget, it’s also a change to how we view IT expenditure and the associated returns.

This Requires a Change to a Culture of Value

Which in turn involves:

  • That budgeting is a planning process while funding is the process of giving money to achieve a purpose
  • Using Value Stream Mapping to understand how your IT organization budgets and funds today before creating a strategic plan to begin Agile budgeting and funding
  • Piloting the new process(es) and improving iteratively via the use of tools that integrate across the technology and financial lifecycles
  • Maintaining the collaboration and communication of the budget preparation and changes with the product owners and suppliers
  • Celebrating financial success as well as technology success

Reaping the Benefits of Agile Budgeting

So, what does this change in budgeting and funding give you? Example wins include that:

  • Teams are confident in the value of their work, as are suppliers, stakeholders, and customers
  • Governance is simplified; as is reporting, monitoring, and alerting
  • Agility and flexibility of funds is introduced to meet competitive, regulatory, or political changes
  • The decision-making framework is better understood and appreciated by all involved
  • Integrated toolsets help technology teams make products better, faster, and safer, and with justified cost

There’s no doubt that this is a massive cultural change but if the current budgeting and funding model is not allowing for the flexibility your organization needs, then why are you continuing with a broken model? What about instead using the values and framework of Agile to create a new way of budgeting and funding?

Want to receive best practice and informative articles like this one direct to your inbox? Why not sign up for our monthly newsletter?

This blog was written to address a question asked by Ian Clayton in LinkedIn about what is the nexus of service integration and management (SIAM) and DevOps. Let’s start with some simple definitions:

  • SIAM is “a management methodology that can be applied in an environment that includes services sourced from a number of service providers. It provides governance, management, integration, assurance, and coordination to ensure that the customer organisation gets maximum value.” Source: The Service Integration and Management Foundation Body of Knowledge, available at
  • DevOps is a cultural and professional movement that stresses communication, collaboration, and integration between customers that want something that requires technology and the technology professionals that can create, deliver, manage, and improve that idea or service.

To me they pretty much sound the same! Well, they have slightly different views but basically SIAM and DevOps are technology-focused movements to introduce quality, speed, and satisfaction for technology-based services. The difference is where the service is governed as this blog outlines below.


DevOps and SIAM share a common set of values and principles. Reviewing these – using DevOps’ CALMS as a template – is a quick way to ascertain the similarities and differences between the two:

  • Culture: Both encourage a new way of thinking and behaving to deliver and improve a service or product. DevOps concentrates on speed of delivery while SIAM focuses on the governance of that service across various providers. They both suggest a cross-functional team to create, support, and improve the service. DevOps suggests that a product owner owns the service, while SIAM introduces a (small) team called a service integrator to act as the point of control and contact for the product or service.
  • Automation: Both SIAM and DevOps benefit from automation replacing manual tasks, facilitating monitoring and reporting, managing data and information sharing, and creating software that provides the required products or services including the virtual environment and operating system. Both are vendor or tool agnostic but strongly suggest that the tools used integrate across the lifecycle of deciding, creating, testing, agreeing to go live, going live, managing, and improving without introducing delay.
  • Lean: Lean is a customer- and employee-focused way of thinking that looks at the products or services delivered and encourages the people creating them to make it better continuously. This is coached by management in a top-down manner and if suppliers are involved, a lean organization would ensure that they are also involved in the improvement of the end-to-end value stream.
  • Measurement: You cannot rapidly create, design, deliver, and manage a technology-based service without some view of what is good, bad, or great. And metrics should cover cost, quality, time, satisfaction, compliance, reporting time, fix time, etc. DevOps suggests that these metrics are flexible enough to allow teams to do what they need. SIAM adds a layer of governance for the service provider(s) and helps to ensure that escalation and resolution are performed as required.
  • Sharing: If culture is about how to change an organization to adopt the agility, flexibility, and opportunities of best-practice technology movements such as SIAM or DevOps, then sharing underpins that change process. Sharing knowledge of what’s going to happen, practices that have worked, suitable tools, and the requirements of people or processes truly drives the innovation of services and the reduction of technical debt.

DevOps and SIAM in action

Think about the lifecycle of technology – you get a request, build a case, do some design, code your service, test that service, enable the service to go live, and once live fix any issues or add features until the product or service is replaced or removed.

How can you improve that flow of work with the right people, processes, tools, and governance to perform these activities and improve them overtime? DevOps will help from the technology aspect and SIAM can help provide the governance layer for that service or product (if multiple suppliers are used).

You have a value stream of activities across the product/service lifecycle that can be measured, discussed at all levels, improved with the use of technology, and delivered to the customer in a consistent and reliable manner. SIAM is going to suggest that you create a strong governance but DevOps will encourage that this governance structure be flexible enough to not stifle the agility of delivery and improvement. Which leads to the culture of sharing and improvement as mentioned above.

So, there you have it – there is a nexus of SIAM and DevOps and it’s ultimately about how to best integrate the providers of services that employ technology to help organizations remove obstacles and achieve their goals.

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.

One take is by Mark Schwartz (CIO of US Immigration) in his book The Art of Business Value, that value is:

“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?

Image Credit