How Shell Oil Is Taking DevOps and Agile to the Cutting Edge
According to Gregory Dubus, the global supportability and transition manager at Shell International, the future of DevOps and agile project management should be focused on supportability and transition. Speaking recently at DevOps World in London, he pieced together the building blocks for the massive agile and DevOps transition at one of the world’s largest enterprises.
He said, “At Shell, we are not using the term agile, we are using the term ‘Edge.’ Edge is a wrap up around Scrum and DevOps.”
At Shell, they use Edge as an umbrella term to cover the embedding of agile and lean principles and practices across the whole company, which grew out of an IT initiative.
Project Edge began in 2010 because “We needed the IT solution to change as fast as possible,” a faster, cheaper way to deliver projects and to remain competitive.
Just how did they accomplish this agile at scale?
Cutting Edge: How Shell Implemented Agile Downstream
Edge is what Shell calls its “cutting edge” way of blending an agile project delivery approach with scrum for an agile software development lifecycle. It also uses DevOps to enable continuous delivery, while retaining some aspects of traditional Waterfall project management.
The objective is, by 2018, “to get Edge across all our businesses for world-class project delivery,” Dubus said.
The first step in implementing this widespread transition from completely Waterfall to the “sprint, learn, succeed” mindset of Edge was to decide where and where not to implement it.
Edge is deemed most beneficial to projects that require one or more of the following:
- where speed to market is critical.
- prototypes and proofs of concept.
- “fail early” for smaller iterative releases.
- things involving non-business-critical applications.
- would not require the work commitment of more than six to eight team members.
Dubus added that “We like to use it when the business requirements aren’t clear.”
Edge was deemed ineffective in the following situations:
- where there’s resistance to adapting to new ways of working.
- when a business cannot commit the necessary resources.
Below you can see the ladder diagram explaining more in depth the Edge Project Delivery Process.
This bi-model agile-Waterfall methodology approach again involved distinct tracts and criteria to decide when to apply which model:
- Agile is applied when there’s an uncertainty, a need for quick decisions, flexibility and early delivery.
- Waterfall is applied when safety, accuracy, predictability and control are priorities.
Shell’s delivery method differs from smaller companies which implement agile almost automatically as par-for-course. Here, Shell project managers “don’t think always agile first,” Dubus said. “It depends on what we need.”
Below you can see a visualization of how these delivery methodologies are implemented, noting how DevOps and agile involve short iterations while Waterfall follows an inherently longer, slower process.
How Shell Became More Competitive via DevOps
“DevOps means you do something and you put things in production,” Dubus said, explaining how, with Edge, they are somewhere between agile and DevOps because it varies when they put things into production.
He continued that “DevOps optimizes collaboration between development and operations, enabling faster, more predictable, more frequent releases.
He said that development teams are doing a lot of agile in DevOps already and expressed excitement as they work toward automating everything, integrating autonomously and updating the source code.
For Shell, the value proposition of the rapid iteration of DevOps is to “deliver and enable business capabilities that generate value faster whilst maintaining operational and security.”
Shell project managers are working on the tools to make sure they are secure so they can go fast. After uncovering a need for clear handrails of what is DevOps and what is not, this past year, Shell provided a DevOps 101 training for all Shell IT employees to learn more about this kind of change and release management.
Above you see the conceptual framework driving this company-wide initiative toward cracking down silos to create one team.
Dubus said that before enacting the Edge initiative, the company was heavily relying on consultants — about 50 percent of the staff on IT projects — and now only five percent of IT is consultants.
But How Do You Measure Cultural Change?
Of course, being the fifth wealthiest company in the world, measuring its success is a priority. Beyond the impressive reduction in consultants we mentioned earlier, since its implementation, the project has found:
- 100 percent of business users surveyed were satisfied with the value, quality and speed of solutions.
- 97 percent of business users surveyed were satisfied with the cost of said solutions.
Of course, another important way to measure success in the oil and gas industry is whether or not it complied. For agile and Scrum in the heavily regulated worlds, certainly “compliant” is another definition of “done.”
Measuring cultural changes is always a challenge, but it’s a particular hurdle for such a large multinational. At the end of October, Shell released the following learnings from the Phase I Pilot:
- Operational and Assurance resources need to be included in the DevOps teams.
- Cultural and mindset changes remain a key challenge.
- Despite the large decrease in service and infrastructure contracts, managing the rest of the contractors and including them in the new DevOps structure continue to present a challenge.
- Budget and cost of implementation are still unclear, which will of course influence determining the true business value of the project.
- Automation is still too slowly progressing.
- Even in the pilots running the longest, the continuous delivery and deployment of DevOps is still not fully achieved.
These realizations led to the following recommendations:
- DevOps is a new approach for many members of the operational and development staff, which means retraining must occur.
- They still need to clarify what is DevOps and where it should and should not be applied.
- There’s a need for increased strategic engagement, explaining better the value of DevOps before continuing to implement it.
- Coaching should be provided to new DevOps teams.
- DevOps buy-in and support is required at all levels of business and IT.
- During sprint planning, all functional and nonfunctional requirements must be a part of a single product backlog.
- The automation tooling journey must be continued, including an emphasis on continuous integration, automated testing and continuous deployment.
- They need to bring in external examples and lessons learned at other companies to discover more DevOps best practices to potentially follow.
As you can see, Shell has a long way and a couple years to go. But this is one of the largest scale DevOps and agile initiative taken on by a major multinational company. Even as a much larger enterprise, It shares the same challenges as startups — resistance to cultural change and measuring for success. Only when these hurdles are overcome can it then be determined if DevOps is a success or just a passing fad.
