CAMBRIDGE, Mass. — Plagued by technology debt and driven by competition to innovate at a quicker pace, businesses are confronting which development methodology is right for their business: bimodal or agile.
The successor to the waterfall, agile development practices have become standard operating procedure for project management. Agile allows technology teams to move quickly with shorter release cycles emphasizing iterative and incremental project advancements.
But not every team can move at such a rapid pace, which has given rise to the emergence of bimodal development.
Bimodal focuses on two modes of development, used to manage different styles of work. One mode is dedicated to "planning and predictable change" while the other focuses on "experimental and disruptive change," according to Gartner.
Emphasized at the Gartner CIO Symposium/ITxpo in 2016, bimodal intended to allow for both fast and slow development to interact in concert.
While the two-track bimodal approach "is a great right now solution," it doesn't work as a "forever solution," said Melissa Swift, global leader for Digital Solutions, Korn Ferry Hay Group, speaking Wednesday at the MIT Sloan CIO Symposium in Cambridge, Mass. Organizations need to gear up on an enterprise level to move at digital speed.
The problem with bimodal, however, is it doesn't work as organizations scale, said David Gledhill, group CIO and head of technology and operations at DBS Bank, speaking Wednesday at the symposium.
The minute organizations are given the "excuse" bimodal is acceptable, three-fourths of them are going to move slow. Instead, every person and system has to change.
The advice? "Move," Gledhill said.
To others, the exact development methodology does not matter. "It's all about having short intervals" with a constant feedback loop to ensure products are moving in the right direction, said Andrei Oprisan, VP of technology and director of the Boston Tech Hub for Liberty Mutual, speaking at the symposium.
But to make it work, tech teams and business stakeholders most operate together. Development groups need to work directly with customers and understand pain points directly. The business side also has to understand the technology challenges and architectural investments that are required, according to Oprisan.
Adapting for change
Agile alone is not enough either. Companies reliant on agile as a "full-blown" culture change solution are missing the point, according to Swift. Agile is a only a part of cultural change efforts.
Though seemingly trivial on the surface, debates about organizational operational models matter. Choosing between bimodal, agile or the dated waterfall methodologies can dictate how quickly organizations deliver products.
With customers demanding a rapid pace of product deployments, pace matters.
For Gledhill, part of the inspiration for learning how to operate at scale comes from companies like Google and Netflix, which have mastered how technology and culture works together.
To reinvent the engineering culture and unlock talent across teams, DBS Bank boiled down the shift in operations and determined what they needed to do, according to Gledhill.
The transformation took five prongs:
Moving from discreet project to platforms allowed for more operational freedom and innovation
Implementing agile at scale
Encouraging the collaboration of DevOps and business to allow organization at scale
Building for modern systems by creating smaller systems built for scale
Encouraging the automation of the whole tech pipeline
With more established and fluid engineering practices, DBS Bank was able to increase automated testing and rapidly improve its product release cadence.
If a team is moving slow, they need to have automated acceleration, said Gledhill. Bringing platforms and teams together with joint key performance indicators can accelerate innovation and help drive slower moving teams.