DevOps

DevOps in a Baltic business context

Next Story

AI-driven service automation: the future of IT

One of the Open Space sessions at the DevOpsDays event in Riga in September 2017 was “Business-IT relationships”. Seeing as this is one of my enduring interests, I couldn’t resist attending. The guy who proposed the topic explained that it was born out of frustration with his dealings with business people. In order to get a better grip on the situation, I suggested that we identified the kind of behaviour that IT people would like to see from their business partners. The group came up with the following required improvements:

  • Give IT people a first-hand understanding of what actually happens in business operations
  • Share the overarching strategy
  • Share the stakeholders and their interests
  • Share the business case so that IT understand the desired outcomes
  • Specify the requirements clearly
  • Set the priorities
  • Provide enough budget
  • Contribute actively during the process, e.g. testing
  • Provide fast, frequent and good feedback

Business involvement

These findings not only correspond with the results of 15 international business-IT behaviour workshops that I have conducted over the past few years, but also with GamingWorks’ global improvement workshops with more than 4000 organizations. In these workshops, two top-scoring ABC (attitude, behaviour, culture) cards for the last 15 years are “Everything has the highest priority according to the users” and “Too little business involvement in requirements specification and testing.” More evidence is provided by the ISACA Benchmarking and Business Value Assessment of COBIT®5: “More business involvement in the governance of enterprise IT is required.” Could this be why “70% of everything spent on IT doesn’t meet the functional goals of projects or deliver the expected return on investment” according to a 2015 NetworkWorld article?

Kill sub-optimal DevOps

I developed the business involvement theme in my Kill DevOps talk (which is probably not what you think). I ask the delegates to consider the broader value stream in which IT is sandwiched between business demand and business use. Where’s your weakest link? In IT or in the business? And if the business is the weakest link, how can you justify investment on improving IT? This is just sub-optimization! DevOps is based on lean-thinking and the Theory of Constraints, and this isn’t restricted to the IT function – it’s about the whole value stream that starts with business need and ends up with the enterprise selling more products and services at higher prices, with lower costs and risks. While much of DevOps’ guidance focuses on ‘IT internals’ such as continuous integration, deployment and delivery, you often need to apply the principles broadly and involve the business in improving flow, feedback and continuous learning and experimentation across the whole value stream.

Product owner – a misnomer

A key business role in the whole value stream is the so-called product owner, who is tasked with determining and communicating the content of the various “potentially shippable software product increments” and setting the priorities with which they are developed. It’s familiar complaint that it’s difficult to find product owners with the right combination of decision-making authority and business knowledge. Oftentimes, this even results in somebody from IT taking on this business role. Perhaps it’s the terminology that alienates the business. The business isn’t interested in “potentially shippable software product increments”, they’re interested in operational IT services. “Product owner” makes as much sense as calling a car owner a gearbox owner. “IT service value manager” is closer: somebody who determines the intended value of the investment and ensures that the value is actually realized. And don’t get me started on the “product backlog.” The term is negative and inside-out, if not inside-in. So, what do you do? “I manage product backlog.” Sounds like sewer backup. Not exactly an impressive pick-up line.

Business leadership

The need for strong business leadership was in evidence in the two The Phoenix Project DevOps business simulations that I ran at DevOpsDays and at Accenture in Riga. Quotes from the participants after playing the first round of the game and discovering the bottlenecks: “separate, unaligned groups” … “bureaucracy” … “the business was always in meetings – wouldn’t listen to IT”. Fortunately, they took measures to improve the flow and the feedback but the message was clear – the game reflected reality, with comments being made that at work, the confusion and corporate politics were even worse…

Porcinification

Do you remember the story about the chicken and the pig discussing an eggs and bacon breakfast? The chicken is involved in the process, but the pig is committed. This ‘porcinification’ characterizes business-IT relationships in the digital era. Now IT is too important to leave to IT, the need for strong business involvement is greater than ever. The business not only needs to be involved, it also has to be committed.

The following two tabs change content below.
mm
Mark Smalley, also known as The IT Paradigmologist, thinks, writes and speaks extensively about IT 'paradigms' – in other words our changing perspectives on IT. His current interests are the digital enterprise, IT operating models, value of IT, business-IT relationships, co-creation of value, multidisciplinary collaboration, working with complexity, and as the overarching theme, management of information systems in general. Mark is an IT Management Consultant at Smalley.IT and Ambassador at the ASL BiSL Foundation. Mark has spoken at 100+ events in 20+ countries.