Rebooting Agile @ GE Transportation

About this Publication

GE Transportation had been on a multi-year agile journey, but recently challenged itself with hard questions: Are we getting what we want? What if we turned everything upside down? What if we leverage our maintenance burden to increase innovation? What if labor capitalization increased our transparency? What if going offshore actually increased our collaboration? This summarizes how the largest builder of railroad equipment leveraged impediments into improvements.


GE Transportation is the world’s leading provider of rail, mining, and marine equipment with annual revenues nearing $6 Billion. What happens when a large company like this moves to adopt agile practices? What works and what doesn’t?

The story is structured in 4 parts. First we will share the GE mandate for building the “industrial internet” necessitated the creation of a detached organization for incubating new ideas and techniques, such as agile development. This leads into how GE Transportation answered the challenge to leverage this new mandate with an initial agile rollout on a specific software program. Second, we share the retrospective learnings from that multi-year experiment, including the need to reboot the program using newer agile methods and a newer internal team. Third, we set the stage for the program reboot, with the specific changes that were made and why. Finally, we reveal whether the reboot achieved the desired outcomes.

These are the topics we will explore in this report, which spans two different teams practicing two very different agile methods for the very same product. The story features a number of key themes we find to be relevant to the discussion of agile methods:

  • The contrast between agile methods for exploring unknown outcomes, versus agile methods for executing known outcomes
  • The contrast between Consumer UX and Industrial UX
  • The false contrast between Strategic work streams and Tactical work streams (Bi-Modal IT)

The authors are those who were tasked to guide the program’s transition from the first team to the second team. Ms. Wenzel was the GE Project Manager tasked to implement the transition, and Mr. Fewell was the external agile coach contracted by GE to accelerate the transition.  Both of us were very certain the original plan was ideal, and both of us were quite wrong.

2.      Background

In 2012, General Electric CEO Jeff Immelt began work on his declared vision for the “Industrial Internet”. To implement this vision, a dedicated Software Center of Excellence (COE) was launched.

It would feature specific organizational attributes [GE NEWSROOM]:

  • Located in in San Ramon, CA, they would recruit the best and brightest talent from Silicon Valley.
  • Setup as a separate GE subsidiary, they would operate free from any cultural or organizational constraints from other GE business units.
  • They would leverage modern innovation techniques such as Lean Startup, Design Thinking, and agile methods
  • New technology would be explored, such as Cloud computing, big data analytics, mobile solutions

Each of GE’s subsidiaries were then challenged to find ways to leverage this center of excellence to explore disruptive new ideas. Among the first pilot applications approved was the modernization of the Maintenance Manager program at GE Transportation.

2.1      The Program

The Maintenance Manager (MM) program manages the software behind the maintenance of freight rail and mining equipment for GE’s global customer base. For example, a freight rail company will periodically send its rail cars to a local GE-certified maintenance shop, whether that company is located in Kazakhstan or the United States. The MM software will be running on devices in that service shop, and is tasked with generating the appropriate work order tickets, maintenance plans, and repair histories for any given piece of equipment. Although the system did its job well, the codebase was nearing 15 years of age, and thus was long due for some modernization and innovation.

The challenge put forward to the program was this: leverage the disruptive innovation practices of the software COE to upgrade the system. Whether it be through dynamic UX, modern database technologies, or analytics, increase the productivity of shop workers, so that they spend less time on the software, and more time repairing equipment.

2.2      The Organization

This MM program was already a distributed organization before this effort began. The Product Management group is located in Forth Worth, TX USA. The IT group is based in Erie, PA USA and reports into GE Transportation headquarters in Chicago, IL USA. By adding the Software COE to the equation, there would now also be additional teams located in San Ramon, CA USA.

In mid-2012, development began in earnest. The San Ramon COE facility hosted four development teams that were exploring new data analytics technologies as a way to achieve the productivity goals. Every two weeks, they would demo increments of functionality to the functional leads in the Transportation business.

As development continued, teams were made to be as self-sufficient as possible, in order to maximize their disruptive impact on the product.  This included self-hosted development and test environments.

This first use of agile methods on the program was a joint effort between GE Transportation and the GE Software COE. Transportation would continue with the program’s operations and maintenance, while the COE would own the vast majority of new innovative enhancements and modernization. This joint effort took place over the course of 2013-2014, before the arrival of the authors.

3.      The First Results & Learnings

By mid-2014, the first major release was deployed, serving as a milestone for key learning both on the product and the process:

3.1      Product Insight: Disruption Works

The first major release was demonstrated to a group of front-line shop workers in the US. After the Product Manager completed the demo, the audience offered him a standing ovation. The new look-and-feel and improved workflow, represented a dramatic, disruptive leap forward for their day-to-day work.

Additionally, the release represented a prototype integration with GE’s next generation software platform, Predix [GE SOFTWARE]. The value offered by the platform was not simply the immediate featureset, but also the strategic potential for the program to leverage cloud computing, analytics, and mobile features.

However, getting these results was not easy.

3.2      Product Insight: Consumer UX is not the same as Industrial UX

One of the key insights during development was the competing emphasis of user experience metaphors. The Software COE talent base drew from the Silicon Valley area, where the school of consumer UX seeks to maximize user engagement with the screen. Engagement is measured by more clicks, and more session time. However, the factories and maintenance shops of the industrial world seek to minimize user engagement with tools. Industrial staff desire to get off the computer, and back to machines and equipment they know and love. Productivity is measured by less clicks, and less session time.

The positive reception from the users in the field was based on repurposing specific UX best practices to fit the lens and context of the industrial user base.  Larger design elements and animations would convey a sense of modernization, but the sheer number of screens would be reduced to minimize clicks and screen loads. This required an additional creativity to achieve a balance between competing considerations. Figure 1 enumerates the similarities and differences encountered.

Figure 1. Consumer UX versus Industrial UX

Initially, the stakeholders and teams were in vocal conflict over these perspectives. However, over time everyone came to understand that we were onto a fundamental advancement of the nature of the industrial internet: Industrial innovation is more than just a copy-paste of consumer innovation.

3.3      Two kinds of agile: explore versus execute

Once the first production releases were completed, senior leadership came to the consensus that the agile-minded Software Center had completed the bulk of its exploratory mandate:

  • They had injected iterative development and agile methods into the Transportation business
  • They had injected automated build and test methods into development
  • They had deployed the next generation Predix platform into field operations.

However, once these innovations were introduced, there was a collective sense of “Now what?” The team was ready to move on to new challenges. However, there was still a significant amount of work left to operationalize these innovations out to the rest of the organization. This crossroads revealed a distinction between two different strategies:

  1. Agile methods for exploring new innovative opportunities. When venturing into an unproven, uncharted territory like the “industrial internet”, there is a great deal of risk. Here, exploratory methods are an advantage for showing whether a “good idea” is actually valuable to the business. This was achieved by the Software COE with techniques like user interviews, visits to the user work sites, frequent demonstrations of a Minimum Viable Product
  2. Agile methods for quickly executing already known and proven needs. Once we minimize the business risk of a given idea, we do not want to incur the overhead of re-proving the idea. Instead, the risk has transferred from the business side (ideation) to the technical side (implementation). Namely, can we build this proven idea with sufficient quality and speed to maximize potential value? Here we would want to explore techniques to maximize momentum, such as large-scale agile programs or organizational transformation.

This contrast in agile strategies mirrors author Jim Collins’ “tracer bullets and cannonballs” [Collins]. When a target is vague, the best strategy is to fire small, fast tracer bullets to identify its location. Once the target is known, the best strategy is to go “all-in” with resources focused on that one point. Agility is about adapting to change. If our key business risk changes from validation to execution, then it makes sense to adapt our agile strategy accordingly.

What began as an exploratory effort would now become a daily execution effort. Measures of success originally centered around ideas and innovation would be replaced with an emphasis on predictability and quality. Figure 2 illustrates the contrast between the two program mandates.

Figure 2. Contrasting Two Agile Strategies

4.      The Reboot

With these insights in mind, the decision was made to migrate the Software COE innovations into the daily operations of GE Transportation’s Services division. Ms. Wenzel was tasked with facilitating the transition, and started new structural elements.

4.1      Go In House

The Software COE was chartered as a distinct GE organization, separate from other business units. To accelerate ideas, the Software COE had operated as a self-sufficient set of agile teams. Executives felt this was the right model for disruption, but not the right model for ongoing execution. We needed a core group of in-house talent to transfer the Software COE’s product and process insights into the ongoing daily Transportation business.

Interestingly, the GE Transportation business also had its own dedicated software center located in India. The decision was made that this Bangalore Service Center would be the new organization to take over the modernization of the MM program.

4.2      Ubiquitous Automation

The new platform was delivered with its own set of documented and automated tests. However, the legacy code base did not have the same coverage. It was decided the new agile teams would extend automation to the legacy code base as well. Over a six-month time frame, 2000 legacy test cases were documented and about half of those were automated using standard technologies like Chef and Jenkins.

4.3      Formal Change Plan

GE also engaged Mr. Fewell, an external coach, to develop a formal change plan. The plan consisted of organizational planning, team-level training, and multi-site socialization of the new team norms.

  • Phase 1- Launching (3 weeks): New program staff would undergo two weeks of orientation and one week of training.
  • Phase 2- Scaling (6 weeks): After three sprints of two weeks (6 weeks), another existing sub-contractor team would also be merged into the program. This would allow all development to be performed by a single integrated organization.
  • Phase 3- Sustaining (6 weeks): After another three sprints (6 weeks), the teams would execute regular improvements, so that they would take ownership of the coach’s activities.

A key part of the change plan involved team design; specifically, how would we allocate people to teams? If we want teams to be long-standing, we have to be very intentional about which skills will be allocated to a given work stream, so that downstream priority changes won’t necessitate reorganization of the team rosters. The program identified a 2×2 matrix defining four kinds of work to be done on the program, as shown in Figure 3.

Figure 3. Four Types of Work

Program leaders determined the best business priority would be to focus energy on Monthly/Legacy fixes and Quarterly/Modernization requests. The other two quadrants were determined to be of lower priority. This yielded the team design described in Figure 4.

Figure 4. Initial Team Design

This was the initial organization that best reflected business priority.

5.      The Second Results & Learnings

The program began executing the change plan in early 2015, with orientation and training. Two teams were initiated and began sprinting, with steady output. The new BSC organization deployed its first release into production in June 2015.

However, that first production release came only after several insights along the way.

5.1      The Team Reorganizes

In response to the team design proposed in Figure 4, one of the engineers declared,

“If we do that approach, I will quit. Sure, the COE got some cool new features out the door, but the pain we went through to get those to work with the legacy technology was brutal. We have GOT to staff every team with a full stack of all the technologies we’re using, so that everything works together all the time. “

Here, the team self-organized its own composition. They were the ones to decide that gaps between the legacy and modern platforms were best attacked at the same time. After much debate, leadership agreed the “full-stack” teams could yield higher quality, which was preferable to the faster-deliver that motivated the skill-based teams.

This modified team design mirrors the emerging trend of Bi-Modal IT, and is illustrated in Figure 5.

Figure 5. Modified Team Design (Bi-Modal IT)

The Bi-Modal approach is one that distinguishes between strategic stable, efficient projects versus agile, rapid projects [Mesaglio]. This allows business owners to respond with incremental urgent needs, while also working on longer-term breakthrough innovation in parallel.

The one side effect was larger team size. Both Alpha and Beta were comprised of 6 modernized skill specialists, 2 legacy skill specialists, 2 testers, and 1 analyst, for a total of 11 per team. However, the team was willing to accept the any side effects from a slighter-larger-than-recommended team. They believed the team design would foster a unified team culture, as well as smoke out any integration issues DURING a given sprint. This was another example where the initial change plan was not as ideal as we thought.

5.2      Bi-Modal IT is a False Choice

Content with the new team design, the teams continued development with the distinct work streams described above.

However, during Sprint three, a team member proposed a “quick release” of newly completed strategic features into the next operational release. The Product Owner agreed, and the experiment succeeded. The new emphasis on quality and automation had yielded product increments that were indeed shippable.

From the business perspective, we had now reduced our strategic lead time from “READY” to “DONE”; the original goal of a quarterly 90 day release was reduced to a mere 45 days. Rather than separating strategic and tactical delivery into distinct work streams, we had integrated them into a single work stream, as illustrated in Figure 6.

Figure 6. Current Team Design

This shows the Bi-Modal IT model described above asserts a false choice between “fast-adaptive work” versus “slow-strategic work”. Once the team began sprinting, they instinctively planned from a single backlog, sliced the backlog into smaller increments, worked as a single team, and operated against common standards.  The result is an integrated program that puts business leadership in a better position: they now have the choice of which incremental strategic increments can be delivered in a given monthly release, rather than having to wait the full 90 days.

5.3      Travel Bridges Distributed Teams

Already accustomed to distributed teams, GE Transportation has an impressive set of tooling and infrastructure around video conferencing and multi-channel communication. However, additional investment was made in targeted travel. Specifically, leadership believed strongly that new India people added to the program should be seen as full an equal employees of the program. To achieve this, Bangalore employees were flown to US offices for orientation into the program, as well as introductory agile training.

The strategy worked. One US-based engineer was so eager to create a team spirit with his India-based visitors, he invited them to his home for a team dinner. That self-organized gesture created significant cohesion for the team.

Later, as more employees were added to the initiative, we the authors flew from the US to India to repeat the orientation and training. This allowed US leaders to see first hand the daily work patterns and impediments, which led to more collaborative problem solving.

Granted, the total cost for this targeted travel is a fraction of the overall labor involved in the program. But it was the executive commitment to the idea of a “single integrated organization” that got the travel approved.

5.4      Culture Bridges Distributed Teams

Transitioning from an all-USA organization to a US-and-India organization meant spanning and additional 7 time zones. Initially, the core work hours for each work site offered literally no overlap in hours. Therefore, the team had to adapt.

Fortunately, three cultural elements helped them to adjust their work hours toward each other.

  • Business needs motivate alternate hours. The core work hours for most GE offices in the US are 8am-5pm. However, the business owners support frequent calls with revenue-generating customers in the Asia-Pacific region, necessitating a modified work schedule. As a result, corporate policy would be trumped by the sales & support culture for “doing whatever it takes to keep the lights on”, including odd hours and working from home.
  • Leaders set the tone. Some of the leaders in the US offices began arriving earlier to the office, in order to create more time-zone overlap with India. Satisfied they had achieved their goals for the day, they would leave earlier. This created the team norm that it was okay to adjust work hours. had a cultural bent for early days, began coming into the office even earlier, and even jumping on calls during breakfast at home.
  • Domestic infrastructure policy. Many India-based GE employees work on global with western counterparts. As a result, it has become part of common corporate practice to offer broadband subsidies, as a way to equip employees to work from home more frequently. Curiously, US-based employees were relatively unaware of the broadband policy. Once they were informed, there was less of a mental barrier to scheduling more cross-continent web meetings.

5.5      Continued Insights

The learnings listed above come from only the first production release. At the time of this writing the new Bangalore organization is still growing into its charter to take over the MM program. We are confident that whatever has been learned thus far is just the beginning.

6.      Summary

For us, the rebooting an existing agile program was a curiosity from the beginning. The conventional wisdom is that, “Either agile fits or it doesn’t”. However, we learned that everything is fit for purpose. Generally speaking,

  • Your agile strategy must align to your business goal. If that goal changes, the agile strategy should change as well.
  • The agile coach is a guide, not a guru. The initial change plan can and should be evolved by the team for the better.
  • Executive willpower and team culture can overcome distributed team challenges. Technology helps, but the desire to connect over distance helps even more.

7.      Acknowledgements

We would like to acknowledge: Kyle Ivany for crafting much of the transition strategy, John Demalas and Thomas Anderson for supporting that strategy, Marc Ballard and Anita Alexander for participating in the strategy. Special Thanks, Jutta Eckstein and Rebecca Wirfs-Brock, our report shepherds for going the extra mile: your patience and feedback literally made this paper happen!



GE Software, “Predix – Your Cloud Platform for the Industrial Internet”

Collins, Jim “Great By Choice” HarperBusiness, 1st edition, 2011

Mesaglio, Mary “Bimodal IT: How to Be Digitally agile Without Making a Mess”,

Author’s address: Julie Wenzel, Chicago IL; email:

Second author’s address: Jesse Fewell, Falls Church VA; email:

Copyright 2015 is held by the authors.

Experience Report

About the Author

No bio currently available.

Jesse Fewell is an author, coach, and trainer who helps senior leaders from Boston to Beijing transform their organizations to achieve more innovation, collaboration, and business agility. A management pioneer, he founded and grew the original Agile Community of Practice within the Project Management Institute (PMI), has served on leadership subcommittees for the Scrum Alliance, and written publications reaching over a half-million readers in eleven languages. Jesse has taught, keynoted, or coached thousands of leaders and practitioners across thirteen countries on 5 continents. His industry contributions earned him a 2013 IEEE Computer Society Golden Core Award.


Aug 2015, Agile2015 Conference


You must be logged in as a Member to download this content.