vege - Fotolia

Waterfall-to-Agile transition: Five tips from Bose

Audio equipment maker Bose's CIO plus members of the development team offer up five tips for making the move from the Waterfall development methodology to Agile.

CIOs today are under pressure to support their company's transformation to a digital business model. One impediment to that transformation can be the speed with which software development takes place within an organization, especially with Waterfall development, the linear software development model that begins with a well-defined concept and proceeds in sequential fashion to finished product. Agile development promises to accelerate that process and thereby minimize app dev as an obstacle to digital transformation.

At the recent SIM Boston Technology Leadership Summit in Newton, Mass., members of the development team at high-end audio equipment maker Bose Corp. shared lessons they learned in their Waterfall-to-Agile transition.

Bose adopted Agile development in 2003, after having become frustrated with the waterfall methodology. CIO Rob Ramrath said Bose had trouble with Waterfall's "unknown unknowns," or ambiguity inherent in the process. He said the company "made a decision to burn the ships," and move to Agile development, which, he said, provides a structured way to avoid ambiguity in the development process and to pull business customers into the development process.

Here are five recommendations that came out of the panel for a Waterfall-to-Agile transition: 

Build heterogeneous teams. The plan at Bose is for all teams to do all projects, so the work isn't tied to any one person -- Bose hasn't fully enacted heterogeneous teams, but it's "an aspiration," according to Ramrath. "How many of you have been working on your backlog, and you've got a project that's queued up and you want to get going, but Mary or Bill with this expertise won't become available until a month and a half from now?" Ramrath said. Heterogeneous teams help remove these scheduling roadblocks. "So [when] the next project from the backlog comes up and gets promoted, you just pull the next team. It isn't about Mary or Bill, or when he or she is going to be available."

Ramrath said the change has brought personnel challenges. The project management group was eliminated, as were teams organized around particular technologies. People who identify as having subject matter expertise in certain areas were now being asked to "deliver broad and deep pockets" around their projects, Ramrath said. "Some people don't want to do that. So, they self-select out. ... It's been a big management challenge."

Collocate all development team members. Having team members in the same physical location and together in the same physical space within that location is critical. Bose team members said that kind of face-to-face communication just can't be replicated using tech-based communications. Panel moderator Jay Leader, senior vice president of IT and CIO at Rocket Software Inc., has witnessed Bose Agile teams in action. "You can see the power of proximity," he said. "There are lots and lots and lots of visual things, on boards and sticky notes. If you're sitting in Pennsylvania [and the rest of the team is in another state], you don't get that."

I can't overemphasize the change management aspect of this.
Wanda Catoedirector of enterprise software for CIS, Bose

Frank Tenore, Agile coach for CIS at Bose, conceded that having team members in distributed locations can work, but said the experience is not as good. "When we first started, we had a couple folks in India. They were in a different time zone from us. They made it work, but they found that when they worked together [in the same location], the amount of productivity spiked."

Having developers work at the same location in an open space does introduce some issues, however. "There are a lot of team dynamics. Soft skills are huge. The very technical cave men or women who like to be head down, not looking at people and not necessarily talking to people -- that's a huge change effort," said Wanda Catoe, director of enterprise software for CIS at Bose. "I can't overemphasize the change management aspect of this."

Determine KPIs to measure success. The Bose development team members noted different ways of measuring success, from knowing that tickets are prioritized in order of their importance to the business -- which is a byproduct of the heterogeneous teams described above -- to the velocity of project completion, as well as impediments to those projects. From an IT departmental perspective, "We really strive to understand objectively how good we are and how fast we are," Ramrath said. The department is undergoing a Gartner benchmark to measure those qualities.

Take a multi-tiered approach to portfolio management. In the past, Ramrath said, portfolio management at Bose was determined by three portfolio managers from the business side who determined the priority of projects. The department had no visibility into the opportunity cost or how development work was enabling business strategy. Today, vice presidents at Bose handle portfolio management across three domains: finance, sales and the supply chain. "It's up to them, over time, if they want to change the resources available to those verticals, they can do that. Those are the big levers." Bose vice presidents can use those levers, Ramrath said, to adjust how much the company invests in IT and how much in each vertical area.

Work to integrate business project owners into the process. The concept of Agile development should have provisions for the business units and IT to work on projects together. "It's not the internal business folks throwing something over the wall, expecting IT to get it done. They have skin in the game, too. They were trained as part of the team," Tenore said.

Next Steps

Read up on myths about Agile development

Determining whether to use the Agile or Waterfall methodology

Crafting Agile project contracts

Dig Deeper on Enterprise application development, DevOps and software agility