The ongoing transformation of ExxonMobil Information Technology began with a fistful of passionate Agile proponents. Along the way, their efforts have led to increased support, influence and a growing portfolio of high-performing Agile teams.
1. Introduction
ExxonMobil’s Agile journey dates back to 2012. Since then, we’ve pivoted multiple times in response to the complexities of transforming a large, 140-year-old enterprise. We’ve also found that, with a large IT workforce, certain tech stacks dating back to the 1960s and a large global footprint bring specific challenges that forced us to forge our own path. We’ve learned to embrace our culture, understand our own organizational limitations and peculiarities, and reshape our expectations for how we’re going to achieve long-term success.
In this report, we’ll highlight where we’ve been, how we approached this transformation differently than other changes in our history, and what we’d do differently if we could do it all over again.
2. Background
ExxonMobil is the world’s largest publicly traded petroleum and petrochemical enterprise. Our operations are global, and our products drive modern transportation, power communities throughout the world and provide the building blocks for thousands of consumer goods. We face the challenge of what “digital” will mean to us and the industries of which we are a part. While digital had dramatically reshaped other verticals, the oil and gas/chemicals sectors have remained on the sidelines. That’s no longer the case.
As part of the ExxonMobil Global Services Company, ExxonMobil IT provides our various business lines end-to-end digital technology support. We deliver custom applications, leverage industry-leading consumer-off-the-shelf software, maintain a hub for key geological and engineering data, and provide base-level IT support. Now that we’re on a more focused digital journey, we also help our internal customers evolve their digital strategy so the entire corporation can match the speed of the market.
Since 2012 (in various forms and functions), our transformation office has provided Agile coaching, organizational leadership and immersive training to transform working groups across the globe into high-performing teams. Though we’ve made huge strides over the last six years, our transformation challenges are still great and some fundamental questions remain:
- How do we continue to support teams once they’ve made it over the hump?
- How do we help project managers learn the skills needed to operate in the new world? (Yes, even with a complex Agile environment we expect to continue running a lot of projects.)
- How do we give developers improved technology and skills to continuously deliver value?
- How do we foster a learning culture that enables people to drive future transformations?
3. Our JOURNEY
3.1 First steps
Let’s flashback to 2012: At that time, pockets of teams were practicing Agile across the organization. They convinced teammates and customers to try out this new way of working by attending conferences, going through formal training or citing past experience. These teams were disconnected but having great success without a central support network. As they began hearing about each other, a semiformal group, the Agile Community of Practice (ACoP – our heritage team) formed to help provide hopeful Agile adopters some thought leadership, guidance and training.
When we looked around the organization, we saw all the classic Agile foils:
- Tenuous prioritization of work. Everything was “important” – nobody knew where to start so we tended to start everything.
- Lack of systems thinking. Being a large group, we were organized primarily on functional specialization and resource efficiency. Communication between teams and their customers, as well as comprehension of the flow of value, was spotty at best. That meant a lot of handoffs and waste.
- Heavy technical debt and little consideration for cost of delay. Due to a focus on organizational efficiency and a high bar on project NPV that didn’t always account for total cost of ownership or cost of delay, new functionality was regularly prioritized over investments in improving and automating existing systems and tasks.
As members of the ACoP, we saw a huge opportunity for the organization to embrace agility, solve some of our aforementioned challenges and create an engaging work environment. We began to build out training materials and conduct “talk show” events while working our other jobs in the hopes of convincing the rest of the organization we saw an Agile way forward.
We wanted to spend time working across the organization and focusing on big changes, but we realized our focus was best kept on helping individual teams find success on their journey. When that success became apparent, others started to believe in this new way of working. Every win felt small, but they each led to additional opportunities and opened doors to conversations we didn’t think we’d have. All these efforts built momentum toward a tipping point we hoped would come soon.
Several times from 2012 – 2014, we pitched having official Agile staff to support the entire organization. We were turned down every time, so we continued conducting informal/ad hoc Agile coaching and education sessions as ACoP – and it worked. ACoP projects benefited from increased transparency and throughput. We saw projects embrace significantly more iterative delivery processes baked into their plans, which opened the door for us in the broader Projects organization. By focusing on the areas where we could deliver clear wins for IT and the business, we proved the validity of agility in the organization and justified the 2015 formation of the four-person Agile Support Center (ASC), the first time ExxonMobil IT had a staffed team of Agile experts.
As the ASC, our job was to support teams attempting to use Agile and Agile engineering practices. Additionally, we were charged with upskilling the organization and providing a culture that would enable this change to thrive. We received consistent requests for “the basics,” so we worked hard to pull together additional training material and introduce formal courses. To help us better understand organizational impediments and lend a hand with course preparation, we pulled in external consultants who voiced concerns about:
- Globally distributed staff w/ lack of co-location and stability
- Lack of transparency of work at all organizational levels
- Watermelon reporting (green on the outside, red on the inside)
- Lack of interest in iterative solution vs. perfect “big bang” delivery
- Lack of DevOps/Agile engineering practices
The consulting group collaborated with us on a seed for our first version of “Agile 101,” but we quickly learned that no external consultant would be able to help us clearly articulate ExxonMobil’s unique organizational challenges or how we should attempt to overcome them. Therefore, we began working on our own material which included a re-draft of Agile 101 and all-day courses for teaching the Scrum and Kanban frameworks with homegrown games – helping us get our first real foothold in upskilling the organization with Agile.
With so much to do, and such a small team to do the work, we were in complete chaos trying to keep pace with all the incoming requests. We were overloaded, struggling to grow and generally doing a terrible job of holding ourselves to the same principles we were teaching the rest of the organization (namely WIP management and transparent prioritization). We still made progress and found a way to deliver value, but it didn’t feel right and we weren’t making the big impact we’d hoped to make … yet.
3.2 Great strides
By 2016, four years since the founding of ACoP, the ASC was supporting 120-130 teams. As teams began to see real measurable success – e.g. 300 percent increase in throughput and 50 percent reduction in incident tickets – select leadership began to ask what an Agile transformation would look like on an organizational level rather than a team level. This came as a wakeup call for us and we had to focus, limit our WIP, and build/execute on organizational transformation plans.
With this, we brought in pieces of an industry standard scaling framework and began to explore what an ExxonMobil scaled environment might look like. In our Financial Applications and Manufacturing & Supply Applications groups, leadership was interested in adopting Agile throughout the full organization. This was something we’d never done before, so we brought in a third-party transformation coach to pair with one of our most senior internal coaches to help us get started. This helped us answer some fundamental questions and build a strategy for tackling an organizational transformation of this size.
With the help of our partners, we took a hard look at how we were delivering value to the business in our current state. We realized that as our demand and traction grew, we never tackled some of the fundamental organizational impediments that always slowed us down. The ironic similarity to a “traditional software development team that struggles to invest in reducing technical debt that will allow it to move much faster” did not go unnoticed. So, even with the pressure to do more and launch more teams, we realized the need to start working on less tangible, more strategic issues, including:
- Providing better guidance for leaders
- Figuring out how to operate within our current funding model
- Seeing how performance assessments work for an Agile team
- Measuring transformations from an organizational standpoint
- Exploring the outcomes to measure against to show added value
The demand for our services, however, did not subside, so instead of taking the time to level up our internal folks, we continued to get more and more of our coaches through consulting services. They provided huge value for teams, so it was worth the investment, but this approach made it difficult to set some pace and prioritize getting the right internal people leveled up to be able to sustain the change.
In early 2016, we had a breakthrough. The organization woke up, read “The Phoenix Project” and started to look at what it would take to embrace the “three ways” within our environment. While the conversation on agility was happening in pockets, a greater number of people were jumping immediately to DevOps, which in some parts of our organization is still an umbrella term for “all of the buzzwordy things.” In short order, a study was chartered on what incorporating these new practices would look like from a technical and cultural standpoint. Immediately after that, a DevOps Strategy organization was chartered and asked to start transforming the way we work.
Rather than diverge onto a separate path of discovery, those commissioned to study DevOps quickly realized there was an opportunity to partner with the ASC. In retrospect, this decision to work together toward shared outcomes was one of the biggest enablers for the success of our transformation office.
Part of bridging these two methodologies was understanding where the DevOps technical practices fit in with our existing coaching engagements. We starting looking for opportunities to plug some of our technical experts into teams that needed help building CI/CD pipelines, building out APIs or adopting test-driven development practices. Our work in driving Agile practices would be for naught if we didn’t have teams pushing solutions to production at the end of every sprint, which, unfortunately, was the case for most teams within our legacy environment.
We also wanted to look at opportunities to bring technical practice coaching in alongside our Agile coaching. We continued to struggle with internal staffing issues, so we knew it would be difficult to consistently deploy technical coaches into our transformations, and we continued to look for other ways to effectively demonstrate the value of a comprehensive transformation. This is when we were introduced to Target and their immersive learning Dojo.
3.3 Enter the Dojo
Dojo means “place of the way.” For the purposes of an Agile transformation, it’s an environment where teams can be fully immersed in the Agile way of working and put its methods into practice under the careful watch of coaches.
During Agile 2016, we saw what another large corporation was doing with their Dojo and immediately reached out to see if we could learn more. Our relationship with the coaches at that organization has become a productive and valuable external relationship that has resulted in unequivocal value delivery for our internal customers. They helped us understand their vision for the Dojo, which we quickly brought back to our home base in Houston. There we pondered what the implementation of a Dojo might look like for our organization, including how we’d be able to gain approval for the facility costs and coaching needs that would accompany such an endeavor.
In mid-2017, we began piloting our Dojo service by focusing on teams we felt were of high business value, were ready to commit to a significant change in the way they were working, and had the management support to ensure they didn’t backslide once they left. Each of those pilot teams left with significant gains and has helped us preach the good word of “true agility” across IT. Feedback on the Dojo experience has been consistently positive but has pointed out some points of failure with our other coaching services. We regularly hear comments like “the flavor of Agile you guys teach in the Dojo is so different from what we’re hearing or driving toward.” This has been a wonderful feedback loop into the coaching our transformation office was doing. It helped us realize that people were hearing about the rainbows and unicorns of Agile but struggling to identify what it meant for them.
Since its launch, 15 teams have run through our Dojo experience, and we honestly cannot keep up with the demand. The value of these team transformations has been recognized by all of our senior leadership, and our VP of IT now refers to the teams that have been through the Dojo as our organizational “Seal Teams.”
3.4 Current state and beyond
As we began understanding how to bring all these practices together and streamline our service offerings as a transformation office, ExxonMobil IT senior leadership decided to make a significant financial investment in our efforts. That included bringing the teams together into a single functional unit (remember, ASC and DevOps Strategy were separate) and clarifying short-term objectives that could be used to justify longer-term investment in transformation (since we all know transformation doesn’t come cheap). The biggest benefit to the change was driving a bit more simplicity into our reporting structures and administration – the team had truly executed as a virtual organization that planned together, worked together and played together.
The other big change has been that we are working to drastically limit our transformational WIP so we can do transformations the right way and still focus on removing the more strategic impediments in the organization. We’ve built a three-tiered coaching model that provides focused coaching for prioritized organizations (or capabilities), some shared/pooled coaches for those starting out, and self-learning material to get people started down the path of what we view as the non-regrettables (i.e., forming encapsulated teams, beginning to understand their work and priorities, etc.).
The shift to limiting our own WIP has been challenging. Telling a team or organization they’re not currently prioritized often elicits a knee-jerk reaction, something like “OK, so I’ll just go get my own coach and do it on my own.” This creates risks of inconsistent messaging and driving the organization in different directions. Though we try to mitigate these risks through our other tiers of coaching, we don’t catch it all. That being said, we believe we’ve found many pieces of what it takes to drive lasting change in our organization and we do ourselves a disservice by reducing transformational quality by “spreading the jam too thin” to try to make everyone happy.
Limiting our transformation WIP allows us to focus and start to ask some of the right questions about scaling, end state, transformation approach and where to invest in our organizations to get them to a point of sustained change. We literally had people who referred to Agile under the name of the scaling framework, which told us that we were no longer focused as much on the principles and outcomes and much more on “checking the box.” This is a bit ironic, as the framework points so strongly back to these very principles, but somehow that gets missed.
As the organization comes to a greater understanding of what our transformation will look like, based on signals from other corporations, we are learning that our “full career” hiring strategy is leading to new challenges we haven’t faced before. For example, we know from industry data that within corporations that transform, some see approximately 30 percent staff turnover before they get to steady-state. Our senior leadership is becoming more and more aware of this trend and has expressed, very broadly, that they do not feel we can afford to see similar results. This puts significant ownership on individuals and their development managers to ensure we are effectively balanced across all of the skill areas we need to be successful.
For particular technology stacks where we know the demand for talent outstrips our staffing ability, we have traditionally taken an approach to fill the gap with external staff augmentation (whether via a major consulting firm or local contractors). While this approach has worked reasonably well in the past, we recognize that the pace of change means we have increasingly shorter cycles in which to begin upskilling our full-time staff before they feel reduced as technical experts. Some have taken the approach of bringing in experienced hires, and others have recommended pairing campus new hires with experienced consultants for rapid knowledge transfer. We are working our way through the costs/benefits of those approaches and finding it’s likely a healthy mix of the two.
4. What We Learned along the way
Much of this came out in our discussion of the journey we’ve taken, but we wanted to (in true retrospective fashion), share a bit of what’s gone well, a bit of what hasn’t gone well, and a few things that we would have done completely differently if we had it all to do over again.
4.1 What’s gone well?
The creation of our initial staffed transformation office (the Agile Support Center) pulled in a number of the most passionate folks in the Agile space. Though this group was small, it also would not take no for an answer and felt very passionately about the need to drive change in the company. Without the team and its energy, we may never have ever gotten the traction for real transformation that we have today.
The creation of the Dojo is still the number one place across our transformation that we can see big, lasting results. The tie between hyper cadence, immersive learning (with a team’s real work) and dedicated coaches in both Agile and engineering practices has just flat-out worked. This model of learning will stay around for a long time (way past getting to Agile) as a way for people to upskill in the organization.
Focusing on quality of transformation and leveraging the pace at which we transform the organization (i.e., our transformational WIP) has and will continue to be key to driving change that sticks vs. “check-box” Agile implementation.
As opposed to randomly selecting teams who were asking for help, the shift to swarming an entire organization with squads of coaches seems like the right move. When we focused on a single team at a time, they would go back into their organization and start to struggle. Sometimes this happened with other teams who may not have been working in an agile way. Other times it was management who wasn’t knowledgeable about how they should interact with an Agile team. By tackling the organization holistically, we’re able to change much of the system around the team at the same time, which creates a better environment for lasting success.
4.2 What’s not gone well? (i.e., speed bumps along the way)
As we began to look at organizations with complex dependencies, we started to churn on what scaling would look like for ExxonMobil. As teams were talking in what felt like seven different languages, we went to our leadership team and aligned on using a single scaling framework as the backdrop for these conversations (as opposed to talking guilds, tribes, trains and unicorns). We did not expect what happened next. A number of folks heard or read the meeting minutes from the leadership team discussion, and very quickly decided that they needed to run toward stamping the aligned framework on their organizations. For some business contexts this will work very well. Others will experience a longer journey to get to the right level of agility, and a standardized scaling framework may be overkill or simply the wrong thing. This is not a knock on these frameworks but a recognition that trying to implement them without a view of little “a” agility has caused us a bit of a stumble and a need to double down on the principles of Agile.
As we started our transformations, there were plenty of opportunities to chase quick wins, so we didn’t do a good job defining either organizationally or with each team what “done” meant from a transformation perspective. We’ve now defined that as getting teams to the point where they can sustain this change themselves, but we’ve realized the importance of setting up outcome-based coaching to get us there. There is a tendency to continue investing in a transformation to go and solve the next big thing, even after the organization has grown the right people to be able to solve those problems. Having a “transformation going” is a great support structure (or safety blanket for some), but it’s not necessarily the right move given the context of getting other parts of the organization up the curve.
For the early part of our transformation, we have been able to rely on quick wins and positive experiences to drive the justification for transformation. On a positive side, this meant we could focus on tackling challenges, but it also has meant that we have not yet found a perfect tie from transformation work to real business outcomes and, more importantly, business dollars. This is a major focus for us moving forward.
Even with the success of the Dojo in pairing engineering practices with Agile practices, we have not completely sold the organization on the criticality of both of these. We still often hear conversations that sound a lot like “Yeah, of course, but we’ll just focus on the Agile stuff for now. DevOps can wait.” To build an organization that can compete in the digital future, we must continue to invest in this space.
5. Acknowledgements
Special thanks to our shepherd from Agile Alliance who helped to guide us in preparing this report.
We wouldn’t be where we are today without the hard work of everybody who’s ever been part of our team and all of those across the ExxonMobil organization who are driving towards real change. This includes all of the key members of our original Agile Community of Practice, the Agile Support Center and DevOps Strategy teams, and the current and past members of the Evolve organization. We love you guys.
We are also thankful for all of our external partners for their advice and help so far over the journey.
Last but not least, we especially thank our amazing marketing and communications team for all of their support in creating this report.
—
Michael Adrian is the Head of Coaching for ExxonMobil IT. He has quite a few passions in his career, but most of them focus on one main goal: working with awesome people on challenging problems. His background is in slinging code for technical applications (which he still loves), but he now focuses on helping teams reach their ultimate potential. In his spare time, he enjoys playing guitar, restoring classic cars, and racing anything with wheels. He lives in Spring, TX with his wife (Lindsay) and dog (Noble).
Jeff Rosenbaugh is the IT Transformation Program Manager for ExxonMobil IT. He is known as a force multiplier and has been accused of having a “larger than life personality”. He has spent his career coaching on innovation, searching out bleeding edge technology, and evangelizing an Agile/DevOps organizational transformation. He hails from Brigham Young University and lives in Houston with his wife (Hayley) and kids (Porter and Kit).
