NOTHING trumps extra pizza on IT projects. Not even more people
Why Jeff Bezos laughs at your 'big' team
Dilbert might mock the mythical man month, Fred Brooks’ argument that “adding manpower to a late software project makes it later,” but most enterprises still think they can hit their deadlines by hiring more people, feeding ever larger teams, rather than by embracing DevOps-friendly practices that favor small teams and high communication between developers and operations.
How much is “most”? Well, according to 451 Research survey data, 60.4 per cent of enterprises address rising release demands by “adding staff to our team.” This despite plenty of research - and Amazon chief executive Jeff Bezos - showing that smaller teams that “can be fed with two pizzas” are the most productive.
Why won’t we learn?
Move faster by breaking things
It turns out to be really hard to change organisations and many, like insurer Hiscox, are set up in uber-large teams that serve as functional silos. Hence, companies end up with development, operations, support, and more, each with its own agenda.
As Hiscox enterprise architect Jonathan Fletcher writes, the key to DevOps, and increasing the pace of change within an enterprise, is to break up the silos into smaller, cross-functional product teams:
We moved people into roles that were more aligned with the business unit... Each product team has its own business analysts, developers, testers and other functions as needed. These teams are the masters of their own destiny, rather than trying to beg and borrow capacity from a big group function.
These atomised teams have all the functions necessary to making decisions and putting out product. According to Fletcher, moving to this DevOps approach resulted in a reduction in its cost per release on one application by 97 per cent, driven by a reduction in time per release by 89 per cent and a reduction in staff needed to release by 75 per cent.
With results so dramatic, why would any enterprise not give DevOps a try?
DevOps is not for me
According to Nigel Kersten, chief information officer for Puppet Labs, a number of factors hold enterprises back from the DevOps dream.
In an interview, Kersten acknowledged “a host of myths surrounding DevOps applicability in enterprise environments that block adoption in many organizations,” but as he pointed out, these myths tend to be held most firmly by those least qualified to comment.
According to Kersten: “These are often views held by technical managers and executives rather than the grassroots practitioners,” which “makes sense for what has been largely a grassroots-driven collection of practices.”
Speaking specifically of those that use regulatory compliance requirements as a reason to eschew DevOps, Kersten called out the following:
- DevOps is more than just development and operations, and should be inclusive of all entities required to deliver business value, including the audit and compliance teams
- IT automation removes much of the human intervention and manual manipulation that slows and pains the audit and compliance processes
- Automated, repeatable processes are easier to audit, easier to understand, and easier to secure, which enables the shift from merely passing the test, to securing the business
In short, the reasons many enterprises cite for avoiding DevOps are often the very reasons they should embrace it.
Small, fast, and possible
According to Gartner survey data, 25 per cent of Global 2000 enterprises will embrace DevOps this year. That’s a clear indication that DevOps has moved beyond a niche cultural phenomenon into a real force for change within the enterprise.
But it also means that 75 per cent of enterprises keep ordering too much pizza, as it were.
It’s become cliche but it’s true: no enterprise can afford to lumber along at a 20th Century pace. Mobile, cloud, and big data are shaking up how entire industries operate, and DevOps is increasingly the organizational fuel necessary to keep pace with these changes.
But Fletcher is quick to stress that DevOps is a major cultural change for most companies, and therefore an iterative approach is required. Importantly, that approach needs buy-in from the highest levels of the company: “You need patience and belief from the top dog (CIO/CTO), because you aren’t going to get it right the first, second or third time.”
Still, he concludes: “The results are worth it.” ®