Here’s a quick story. As a business analyst, I worked at a publisher in Oxford. We were interviewing, process diagramming, and so on – that’s not the interesting bit. Meanwhile, in parallel, they brought in consultants from a small company in Birmingham, UK. Two or three folks.
The building we were working in was long and thin, and had an empty upper floor. These guys came in with a massive roll of brown paper, 7 feet high. They shot this roll all the way down the empty floor. They then went and spoke to people and asked them what systems they used, what forms they filled and so on.
Then they stuck literally everything along that sheet of paper. They took printouts of their screens or the forms they’d fill in, stuck them on and joined them up with black tape so you could see the linkages.
When they’d finished, after a few weeks, they got everyone in the company upstairs and said, “There you go!” Everyone was just wowed, “Oh my goodness, I fill that in, then it goes over there, and then nothing happens to it?” or, “That bit is exactly the same as that bit, but done by two different people?” and so on.
It was the best gift the consultants could have given the firm. Was it worth $20,000 (or whatever it cost), just to stick some bits of paper on a big sheet of brown paper? Yes, absolutely. 100%.
The power of visualization is fantastic, and I’ve seen it many times over the years. I recently spoke to a start-up that enables DevOps process mapping and dashboards. They asked me what I thought of what they were doing, particularly given (so they told me) that I was a bit of a skeptic.
So, I told them the story above. In my experience, software development processes are notoriously hard to lock down despite all the efforts to define methodologies and structures. We can go into the reasons over a beverage, but the result is a continued lack of visibility. As the adage goes, if you can’t measure, you can’t manage. And software development is notoriously difficult to measure.
So, what to say to solutions vendors attempting to crack the code of process visibility in the DevOps space? The question is less about the need, nor the epiphanies that can be achieved with a software package (or post-its on a whiteboard, or a roll of brown paper), and more to do with how to succeed when, historically, many have tried and become, with the best will in the world, a point in time fix.
The challenge is twofold. First, nobody in the (non-technical) organization cares enough about software processes to allocate a budget to such tools. For some reason, the business still thinks that software runs itself – it can’t be that hard to write if you have good people in, correct? Everyone just assumes that it’s just smart people creating things.
However, anyone who has built software at any scale knows what a knotty mess we can get into without the right controls. As a strange kind of good news, we’re in a period of belt-tightening, where CIOs are being asked to justify how much IT is costing – the adage extends to, “If you can’t measure, you can’t have any more money,” which certainly focuses the mind.
So, yes, the demand for efficiency can be met with spend-to-save initiatives, which in turn fuels interest in software process tooling, categorized as value stream management, software development analytics or similar. When looking at multiple providers looking to solve a complex problem in similar ways, I often analogise multiple paths up the same mountain – and this space is no different.
To run with this analogy a little, I see multiple vendors, at various stages of development, going up different routes on that mountain. This brings us to the second challenge – that no organization has yet found a repeatable path to the top.
Everyone gets exhausted after a while and starts slowing down. In the VSM report, we have leaders and challengers, incumbents and new entrants all addressing the problem in their own way. Start-ups arrive in the space often through some personal epiphany, their “brown paper roll” moment, if you will.
They arrive, and up the mountain they head, they’re running and running, and they start to slow down… and eventually, over time, they just become a feature in someone else’s platform. I’m reminded of Spanish world champion mountain runner Killian Jornet’s exploits – while we may all aspire to be like such an athlete, he is an exception, not the norm.
What to do about this? One answer, of course, is not to mind too much. A vendor can acknowledge that it will always be a tactical tool, to be brought in when things aren’t going so well. For the vendor, that results in a certain route to market – to switch analogies, a tool for mechanics servicing the plane, rather than the cockpit centerpiece.
A second option is to scope according to what is feasible, vertically rather than horizontally – if you’re going to be in the cockpit, then do one thing well rather than looking to control the whole aircraft. That way, the audience can be defined more precisely and, by extension, the value brought to stakeholders.
Which brings us to the third option. To consider the use cases in which the tool can deliver value. It’s all very well that a smaller group recognises the scale of a problem, in this case; software development is complex and tends to chaos without the right checks and balances. But it’s a big assumption that others – budget holders up to board level – will reach the same conclusion without a giant roll of brown paper to guide their thinking.
So, if the challenge is that the majority don’t want to solve the problem, however clear it is to the minority, then what are the scenarios in which the majority see it as important? Is there another need that the majority are willing to put their wallets behind? And start from there, rather than the development process and cost efficiency?
Right back at DevOps’ manifesto, the Phoenix Project, itself based on Eli Goldratt’s novelisations of project management best practice, the point was always about business challenges – getting customers onto the website, increasing sales, improving supply chains and the like. However, too many tools and approaches are introspective and focused on improving the means, not the end.
We all know just how hard it is to build software, but see Point One: nobody outside of IT cares that much. If we can’t get the money to make necessary improvements, that’s one thing. And it’s absolutely true that the problem exists. But to assume that people will magically ‘get’ that it needs to be solved is quite another.
So, if people can’t be bothered to solve it, what scenario would cause them to want to solve it? Too often in this trade, we’re forced to wait for situations where the problem becomes a crisis – just after a security breach, when a compliance audit is approaching, or when a software package is reaching the end of life.
Alternatively, I would take a design thinking-driven approach, which maps out and prioritizes business results – this is as applicable to end-user businesses as solution providers. For companies, which specific business needles can be shifted through software process improvements, and by how much? And for vendors, what does the composite picture look like across the customer base?
Note, however, that whilst these scenarios might be events worth putting money behind, they are not the end game – which can be described by a company’s vision, mission and strategy. The business itself is the mountain – your own, or that of organizations you serve as a provider. If you are heading up, ask yourself first, what does the top look like? What will you have achieved when you get there?
If the answer can’t be described in business terms, it becomes far less likely that you will arrive. Bluntly, only hold the software process improvement kick-off meeting with a clear picture of your company’s top three targets for the coming period, and how process improvement, tools or anything else will directly make them happen.
And, as a vendor, if you’re only looking to raise investor capital and for a quick exit, I’d argue that’s a false summit. In these digitally transforming times, misalignment between technology delivery and business goals is possibly the biggest cause of bottom-line inefficiency. Be prepared to kick off the journey with a map to get to the top, if you want to get anywhere at all.
The post DevOps efficiency needs to put business goals first appeared first on Gigaom.
Source : DevOps efficiency needs to put business goals first
