The size of IBM Software Group is staggering: 519 major software product titles, 36,000 software engineers, 116,000 virtual machines supporting development and testing, and 44,000 physical servers.
The Need to Reduce Time-to-Development
This sort of scale naturally means that the stakes are high; and in an industry so ripe with disruption, “overdogs” can be overtaken is short order. In today’s competitive digital environment, a slight inefficiency compounded in such volume and at such speed can bring an organization to its knees.
The Results
With a profound need to evolve and limited time to do so, IBM took pains to reinvent itself as a paragon of DevOps. While managing the transition was no simple thing, the results speak for themselves. Consider these numbers courtesy of Dibbie Edwards, VP DevOps for hybrid, continuous engineering and application lifecycle management development at IBM, as quoted by Devops.com:
- IBM went from spending about 58% of its R&D budget on innovation to push 80% innovation investment today
- In 2008, IBM’s time-to-project-initiation stood at 30 days. By 2014, that figure was reduced by more than a factor of 10, taking between two and three days
- Groomed backlog was reduced from 90 days to one
- Sprint test times were wrangled in from five days in 2008 to 14 hours today
- Overall, the company managed to reduce time-to-development from 120 days to three
- Finally, time between releases shrank from 12 months to three
The Process: A Systematic DevOps Embrace
So how did IBM manage all this? The teams examined the work they were doing – from how they worked with their business stakeholders to how they were working with clients – and resolved to eliminate all of the inhibitors and friction points.
It’s taken time, patience, and an endless supply of perseverance, but the commitment to methodically and meticulously identify and redress inefficiencies has proven hugely successful.
The software group focused on uncovering every manual process that it could – things such as how the tests were being created, building more efficient testing tools, and building a page object framework in selenium that its developers could leverage.
With manual inefficiencies identified and senior leadership buy-in secured, it was just a matter of executing procedural and tool-based improvements, and prioritizing how much to invest in clearing technical debt. With an efficient, well-vetted foundation in place, the IBM Software Group could more fluidly build development processes based on DevOps principles and current business objectives.
With that groomed backlog in place, IBM could positioned itself to make more informed decisions at the end of each development sprint – and to pivot, if needed.
That ability to pivot had been a big benefit for the IBM Software Group. Dibbie Edwards sums it up well, remarking, “I recall how many times we would just churn over these decisions and remake them and make them again.” Now, the development ecosystem would support rapid, iterative release cycles. No longer prisoner to operational inefficiencies or strategic dithering, human talent was free to do the rest.
