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.
5 Lessons Learned
- Be realistic: Your organization's unique needs will dictate what can be accomplished in a two-week sprint.
- Over communicate: Don't assume everyone will get it the first time. They won't.
- 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.
- Coordinate teams: They can learn from and help each other; so the closer in alignment they are, the better.
- Cultural change is key: People will have problems with the changes agile brings. Identify passionate individuals and get them to help with adoption.
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 over communicate 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. With more people getting involved, we needed to coordinate the various teams that were all contributing towards 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; and after lunch, 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 else 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's, 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.
For more information on ALM and SCM, download the Dr. Dobb's ALM Sourcebook.