I just got back from two days with HPE Software’s customer advisory board in Las Vegas. I come away all fired up yet also despairing, in almost equal measure.
Fired up because large enterprises really do want to get better at developing software. They’re desperate to learn how to become more like Web companies, with much faster cycle times and the ability to bring new products to market faster. They want to embrace methodologies like agile, use distributed version control systems, improve their monitoring infrastructures, get better at all the things.
Despairing because the question remains – how are they going to get there? The will is there. Senior management understands the need to change. But digital transformation is hard. Embracing software engineering culture is very hard, especially after a few years in the wilderness of IT Doesn’t Matter Commercial Off The Shelf (COTS) purchasing and Big Outsourcing. But there are not enough consultants like Gene Kim, Jeff Sussna and Gary Gruver to go around. The Phoenix Project is great, but after reading it you don’t magically have a DevOps culture.
HPE is now building tools to enable organisations to embrace new ways of doing things. New CEO of the HPE/Micro Focus merger Chris Hsu had great talking points like:
“We embrace DevOps and ChatBots as the new norm for delivering management service. We embrace containers and APIs as the new software delivery model.”
Yeah that sounds awesome, it’s future facing. But ChatOps isn’t a market yet. Ask Mark Imbriaco, founder of recently shuttered ChatOps startup Operable. Vendors can build tools, and integrate open source components that map to Web company stacks and working practices, but that doesn’t mean customers will know how to use them. Change is hard. We keep running around saying oh it’s a cultural problem. Of course it’s a culture problem. Seriously – we had round tables on different aspects of modern development – tools, app dev, ops, security. Every single one of them, the roundup was “it’s a culture problem”. DevOps is a Reorg, says Adrian Cockcoft. Indeed it is.
Do some tools lead to a cultural change? Choose Slack, choose PagerDuty, GitHub, headphones to block colleagues out, Choose Pair Programming. Choose TravisCI, Choose Monitoring, Choose Docker, Jenkins for CI/CD. Choose Ansible, Chef, and Puppet. Choose life.
"by simply dropping two pizzas into any organisation, teams will form around them, and then you have devops" – @phillip_webb #s1p @pivotal
— Grumble Bundle (@monkchips) August 2, 2016
So how do we all become high performing IT organisations, with much faster development velocity, higher quality code, and a culture of operational excellence that runs through every product?
Pivotal is perhaps the only software and services vendor in the industry that has an offering at any scale, and a tailwind in driving this kind of change. Companies are religious about the Pivotal Way. Pivotal has packaged up How To Do Software in a repeatable way. But the kind of training and experiential approach that Pivotal takes, with pair programming formalism, exposed concrete and 9:06 breakfasts, may just not scale to organisations outside the Fortune 100. The rest of us will just have to read a lot blogs, and try to do better.
I talked to an old friend Neelan Choksi, COO and President of Tasktop while I was in Vegas about culture change in tech. He pointed out that we had seen a huge change in software development during Mercury Interactive’s pomp. Software Centres of Excellence, huge budgets for testing, an almost cult-like adherence to the craft. Ironically of course Mercury was acquired by HP.
The last major framework IT invested heavily in was of ITIL. Though ultimately unsuccessful in delivering results ITIL was put together in a way enterprises could understand – there were courses, certification and training, a clear way of talking about roles and responsibilities, with products designed to support those roles.
https://twitter.com/DOES_EUR/status/871649848797405184
And now we’re saying forget ITIL, that sucked, you need this agile stuff the Web companies are doing, but there is no certification, it’s poorly defined, and we can’t really tell how you to do it. Enterprises love stuff like that…
Vendors are now moving ahead with modern development approaches, and building application development and management products accordingly. HPE for example now delivers new features on a 3 monthly cadence. It embraced Git, Selenium, and Jenkins in its products. Oracle has Docker religion. IBM has recommitted to engineering leadership – working with Google and Lyft on a next generation microservices framework called Istio.
We’re seeing amazing work done by enterprises in pockets. Capital One has made a huge embrace of open source style developer meetup culture. Amex is building its own Chatbots. Allstate has an en viable development cadence.
But there is still something missing – a framework enterprises can buy into, which is open enough to allow a broad delivery ecosystem, which packages Agile and DevOps in way that is consumable and allows for significant change. Not everyone wants to change, but companies have no choice. One attempt is the Scaled Agile Framework, but we haven’t been seeing it get a great deal of traction and it feels overly complex.
We do need some kind of standardised approach to improving the interplay of people, process, tools and training but this stuff is hard. Ron Jeffries, one of the authors of the original Agile Manifesto wrote a great, salutary and sort of sad post about all this stuff recently.
“So, I guess, Agile has moved beyond being applied by people who understood it and liked what it gave them, or who liked what they saw and worked hard to learn to get it, into a world where “decision makers”, who don’t even know what it is, decide that those guys down there need some of that Agile Stuff and impose it – impose something – on their organization.”
“Meanwhile, those of you in the trenches, let’s talk about what you can do to survive in this world of Dark Scrum and Corporate Agile”
Meanwhile, Aslak Hellesøy, the creators of Cucumber is also unhappy – he calls it The world’s most misunderstood collaboration tool because folks are using as a testing tool rather than part of a transformation to behaviour driven development, a variant of test-driven development.
So the authors of the methods and tools are unhappy, and enterprises are still not ready to adopt new practices and tools. Other than that we’re all good. This is going to be a research theme for me for 2017. I’d love to know your thoughts on how we can improve software development outcomes and organisational readiness for same.
Docker, Google, HPE, IBM, Oracle, PagerDuty, Red Hat and TravisCI are all clients.
Paul Johnston says:
June 8, 2017 at 8:24 pm
Good post. There’s definitely a desire to move forwards in the enterprise world, but there are real issues.
The big issue as I see it, is the enterprises want to move at the speed of the “startup” and they can’t, because they don’t like mess.
Startups are full of missteps, guesses, rabbit holes, big balls of mud, and time lost on trying to do tech that’s not even possible. Often, breakthroughs happen by accident, or out of sheer luck.
Enterprises do not allow this kind of “mess” to exist for very long. It’s not that there aren’t clever people in these orgs who can do stuff or have great ideas. It’s an issue of management and risk.
If you’re in an enterprise, and you advocate your team to just “go for it” and give them autonomy to make decisions without comeback, it might work. But most likely you’ll be told to give them more direction and control it better or you’ll be fired.
Startups and web companies are exciting because people care about making great stuff, and they are under pressure to make great stuff as quickly as possible (runways!).
A friend often quotes this to me: “It’s messy in a nursery and neat and tidy in a graveyard.”
We do our most creative work when we’re kids, when we are figuring out what this toy does, and how I can use it. That’s a startup.
Enterprises are much more rigid. It is obvious when you look at an organisation that “imposes” agile top down. That isn’t “here’s a tool, play with it”, but “here’s a tool, here’s how you use it, and here’s how it’s going to make your lives better”.
Enterprises need to embrace some sort of culture of mess, with limitations (runways impose time limits on the mess). Startups create cultures around their teams too. The structure is only imposed so that the growth can happen, not the other way around.
Startups are very messy. Maybe it is just as easy as turning every part of your company into it’s own Skunkworks. Can’t see that management approach flying with enterprise company shareholders though…
Minimum Viable Architecture – good enough is good enough in an enterprise - Enterprise Irregulars says:
June 20, 2017 at 10:34 pm
[…] post serves as a follow up to my question – how are we going to achieve escape velocity for modern software development? If enterprises are going to drive a successful digital transformation, and develop a culture that […]