Andrew Deitsch is VP and general manager for GE Healthcare IT's Imaging Solutions group. Ross Hughes is GE Health care IT's ScrumMaster.
GE Healthcare is a $17 billion business unit of General Electric, making everything from multispectral high definition CT scanners to diagnostic pharmaceutical devices. Our Imaging Solutions unit, which has 375 engineers supporting 18 products that increase clinician productivity, a year ago faced several challenges meeting commitments in this multiproduct distributed environment.
First, we struggled with the predictability of our program execution. The cycle time on projects was too long, taking from 12 to 24 months, often with significant delays. These long cycle times frequently caused the business to push to add features beyond the initial requirements, fearing that the market couldn't wait for another cycle to get those features. That, in turn, often increased a program's scope, causing further delays and increasing the cycle time even more. A longer cycle time puts a project at risk since the requirements gathered at the beginning are out of date by the time the product hits the market.
Second, our waterfall process followed the typical phased-gate approach, which begins with gathering requirements, creating a high-level design followed by detailed designs, and then creating a traceability matrix showing how those design details tie back to the system and user requirements. At that point, a formal design review occurs and once the various approvals have happened, coding begins.
Coding typically takes several months, and then we release the product into a test environment where we can collect customer feedback. This is usually the first time customers see the new product before we begin a rigorous verification and validation effort prior to release.
The challenge with this approach is that the ability to incorporate customer requested modifications occurs so late in the cycle that any significant misses could require complete changes to the design, causing a lot of wasted time and effort, and delaying the project further.
A third challenge for Imaging Solutions' product development effort was the many artificial barriers that existed among functions, especially marketing and engineering. These barriers weren't any different than in most large organizations, but it was clear that they were becoming more problematic over time.
To address these issues, early this year, Imaging Solutions replaced the waterfall software development methodology it was using with an agile initiative. We already had pockets of agile development going on within various development teams around the world, but they were run by engineering groups that only used parts of agile. They used Test-Driven Development, Continuous Integration, and ran projects in sprints, but didn't adopt other facets of the methodology.
We liked the agile-based scrum approach of having the product owner as an integral part of the development team. We hoped that adopting agile would break down these barriers and get the whole business working in unison to release the right product to our customers on time. We especially liked the idea of bi-weekly sprints, where product increments were completed, and the chance to demonstrate functionality to customers at the end of the each sprint and get immediate feedback. We began by visiting colleagues at one of our joint ventures who used agile methodologies from the beginning of their development process and were having great success with it.
We sent different people a number of times to observe sprint reviews, retrospectives, and sprint planning, and to learn \ how they use third-party tools — like Rally's Agile ALM platform — to create a single source of record for progress and quality across their software development teams. We also met with the quality and regulatory team to understand how it was making agile work within its Quality Management System. Those conversations got us excited, and we began to focus on getting senior leadership support.
They'd seen the results of using agile development at the joint venture (especially the frequent customer feedback), and were quick to support our move. Our next step was to hire an outside agile coach, who met with the entire team to understand our products, organization, and development processes. Once he assessed our current state, he customized our scrum training.
We decided to launch our move to agile with one team. Then after that team was comfortable, roll it out to one site. And then finally, we could take it to all of our development sites globally.
The objective for our pilot was to acquire scrum experience, understand how we could apply these techniques within our larger business (such as making it work within our Quality Management System), and to build confidence among team members and leadership that we could be successful. Everyone involved in the pilot — executive leadership, managers, marketers, developers, testers, and technical writers — was trained in the scrum methodology. We needed the whole crew on board; we didn't want this to be just an engineering effort.
We staffed a strong cross-functional team for the pilot and protected it from outside distractions. We defined a manageable scope with a short time release horizon of about four months. We established clear success criteria so that we could evaluate whether we achieved our goals. Yet, the project was meaty enough that the team could learn scrum skills while delivering something meaningful to the business.