GE Healthcare Goes Agile

GE Healthcare is a $17 billion-a-year 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.

Agile Transition

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 biweekly 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, as well as 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, 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.

What We Learned

The pilot identified important lessons. First, we operate in a highly regulated environment so there are a number of additional quality and regulatory steps that must be completed before we can accept a "user story"--that scenario written in the business language of the user that captures what he or she wants to achieve. Therefore, our "definition of done"--that is, the list of activities that add value to the product such as unit tests, code coverage, and code reviews--turned out to be lengthy. Our development teams need to plan for that when estimating what they accomplish in a two-week sprint.

We also learned the importance of communicating, communicating, and then communicating some more. It can't be emphasized enough how important it is to make sure everyone from the CIO to the developers knows what's happening. Often people don't hear the message after the first, second, and even third time it's said. So, while it may feel repetitive, it's valuable to overcommunicate and keep everyone aligned.

Finally, we found that we can be agile, but the rigors of being in a regulated industry require us to operate a hybrid development model with more up-front planning and post-sprint testing than would be found in a pure agile environment.

Following the pilot, we brought our agile coach back in to train everyone who hadn't already been trained. We formed 10 scrum teams of seven to nine people and allowed them to self-organize. Even the leaders got engaged by forming their own scrum team.

5 Lessons Learned

1. Be realistic: Your organization's unique needs will dictate what can be accomplished in a two-week sprint. 2. Overcommunicate: Don't assume everyone will get it the first time. They won't. 3. Modify: It's OK to use a hybrid approach to agile. GE Imaging Solutions needed more up-front planning and post-sprint testing, for example. 4. Coordinate teams: They can learn from and help each other; the closer in alignment they are, the better. 5. Cultural change is key: People will have problems with the changes agile brings. Identify passionate individuals and get them to help with adoption.

With more people getting involved, we needed to coordinate the various teams that were all contributing toward a common release. We instituted scrum of scrum meetings with a representative from each of the teams to coordinate activities. We also scheduled our sprint reviews so that they're all on the same day. So now, every other Wednesday, the teams conduct their sprint reviews together in the morning; after lunch, they hold planning meetings for the upcoming sprint. This ensures shared learning among the teams and visibility into what's going on outside any one team's activities.

We also found we needed to identify cross-team dependencies early in the sprint or risk teams getting in one another's way. Rally's Agile ALM platform provided insight into cross-team dependencies and real-time status updates. With these capabilities, we started to see teams swapping user stories and tasks. Teams that complete their own tasks early are helping ones that are slower. There is, indeed, an art to balancing the decentralized control of independent scrum teams.

Cultural changes are the hardest part of adopting agile. That's something we'd heard from others prior to jumping into the methodology, and it turned out to be true. People often find it difficult to change, and so it's important to identify change agents within the organization who are passionate and can help with the adoption. A key aspect of the culture change is the role of managers and individual contributors on scrum teams. Managers need to avoid a command-and-control style where they're pushing work, but rather build empowered teams.

Individual contributors need to start pulling work, make commitments around that work, and then be accountable to deliver on those commitments. Trust is an important part of people being comfortable enough to embrace change, along with providing a safe environment where teams can learn, fail, and bring up issues without fear of repercussion--this is critical for success.

While we've only just begun our journey, we've seen positive results already. Getting feedback early and frequently from customers has let us prioritize features correctly and, in one example, identify a clinical workflow that we hadn't known about. We've seen much more transparency and accountability among our teams. Team ownership has increased, and scrum processes have brought the entire team--from individual contributors to leadership--together, asking the right questions.

The pilot project was delivered successfully with the correct features and functionality. The release ran over by two sprints, so we're still working on the predictability of our execution. Understanding a team's velocity and using it to predict future execution is a learning process that will take some time--and some more sprints--to perfect. However, we're making progress, and we feel that the benefits so far of our agile adoption are worth the effort. We're now beginning the next phase of our transition by rolling out scrum globally to the rest of GE Healthcare.

Andrew Deitsch is VP and general manager for GE Healthcare IT's Imaging Solutions group. Ross Hughes is GE Healthcare IT's ScrumMaster. Write to us at [email protected].