00:00:14

Thank you Simone. So next up is suya Deepak, who is global practices and competency manager at Schlumberger. The number one software technology provider to the oil and gas industry, suya is responsible for all global software practices, governance, tooling, and the competencies and skills needed by the entire software development organization, which includes over 2000 developers. She reports to the VP of technology and they are part of the digital technology organization. She will be presenting with one of her team members, Nigel Lester, who is one of their global ALM practice champions. They will be presenting on their journey, which started as they had to figure out how to move from solutions that required their customers to deploy on premise, to on potentially large numbers of servers, to being a SAS offering, which is critical to maintaining their leadership in the market. They also had to figure out how to satisfy the vast governance requirements of a heavily regulated industry in an organization with over a century of traditions on how one manages risk through making comprehensive plans and through elaborate compliance and documentation processes. Although they called us a talk on governance models. I think this is a very incomplete description because the issues they tackle were much larger than just around compliance, but around objective setting, steering and measurement, these topics will be familiar to anyone who has studied or done OKRs. These are topics that are critical in achieving important goals in large complex organizations. So here's SJA and Nigel.

00:01:53

Hello and welcome. My name is SJA Deepak, and I'm joined today by Nigel Lester. We are from a company called Schlumberger. That is a leading global energy solutions provider. This is the story of adopting a lean governance model for building and operating SaaS solutions in a highly regulated environment. Our story is the work of many from within Schlumberger and inspired by several more ideas, theories and practices from the digital industry and other thought leaders. It is also built owned and continuously improved by the Schlumberger digital community. This is season based governance, but first, what do we do at Schlumberger every day, we work together to create technology that unlocks cleaner, safer access to energy for every community, including those we live and work in our story begins with what it truly means to be a technology innovator. Conceiving an idea is one thing, but making it truly revolutionary means proving it, which often takes patience and perseverance.

00:02:47

Schlumberger's story began with the passion to innovate by the Schlumberger brothers on electrical resistance generated by different types of rock formation. Back in the 1870s, Schlumberger started shop in 1919 in Paris to pursue the further evolution of electrical prospecting as it was called today. Schlumberger has a global presence and its workforce is truly diverse consisting of approximately 92,000 people representing more than 160 nationalities operating in 80 countries and working in 65 technology centers generating more than 13,000 active patents to date. In 2021, we achieved a total revenue of 22.9 billion us dollars. So gene asked us to explain how the technology division fits within Schlumberger and how it delivers value to the business. So with in Schlumberger, we have been building and providing software solution for the entire exploration and production landscape for many decades, our largest software digital segment, Schlumberger digital and integration has over 2000 software technical experts from 80 plus nationalities working in technology centers across north America, Europe and Asia, just the segment alone has a combined revenue in 2021 for around 3.2 billion us dollars.

00:04:05

So the purpose for Schlumberger's digital software division is to work closely with our customers and our digital partners. So that together we create amazing technology that unlocks access to energy for the benefit of all our digital platform, empowers customers with AI and digital innovation, connecting digitally enabled hardware to realize autonomous solutions. Many of our products were on-prem software solutions and until 2017, we were releasing the products in yearly major and quarterly minor releases and yearly releases worked fine for our business needs. Then eclipse for example, is the industry reference simulator and intersect is the new high resolution industry standard simulator. Our reservoir simulators offer the industry's most complete and robust set of numerical solutions for fast and accurate prediction of dynamic behavior for all types of reservoirs and development schemes. The eclipse simulator has been the benchmark for commercial reservoir simulation for more than 30 years, thanks to its extensive capabilities.

00:05:03

Robustness speed, parallel scalability on unmatched platform coverage. These simulator runs are compute heavy and require our customers to plan for their hardware needs or run on setting up expensive client owned on premise clusters. We wanted to enable our customers to be able to run simulations from anywhere without having to worry about the hardware and compute needs. Basically we didn't want simulation activities to be driven by infrastructure. And today we are able to continuously deliver and operate SaaS solutions across the EMP environment. Our flagship solution, Delphi is a collaborative technology that unites the exploration and production life cycle in the cloud. It's open, secure, scalable, fully managed seamlessly, connecting people data and leading software applications across exploration development, drilling production, and midstream all delivered through a flexible and personalized SaaS subscription model. So going back to the simulation run example, we are so proud that our customers can now submit simulations from Delphi or your local environment and utilize unlimited hardware and software.

00:06:08

We have advanced assimilations for enabling automated insights via AI analytics. The entire run is Schlumberger operated and supported. And for our customers, they could shift simulation, run costs from CapEx to OPEX, just a quick plug to what Nigel and I do. We are part of the software lifecycle management program for the digital wing of Schlumberger. And we are responsible for defining and supporting a globally distributed software development community on the practices. We follow agile lean product management, UX design thinking the technology tooling choices for every stage of the software development life cycle provide the digital skills training and coaching needed, and finally manage the software governance needed to enable efficient and secure delivery of commercial software products and services to our global clients. The entire software lifecycle management is an amalgamation of many ideas and it is Schlumberger community owned. We call it the Schlumberger ecosystem for our people to design develop, test, build, and release software to our users.

00:07:10

It's built a four areas. As I mentioned, people, practices, tools and governance in a holistic integrated way. The most important piece is the people piece SM has been built by the people for its people. So delivering this vision of Delphi required a transformation in not just our skills, culture, and technology tool stack, but also in our practices, our governance and the way we innovate and learn. And five years ago, we clearly saw the gap and we knew we had to build these capabilities to succeed. So Nigel tell us what we had before and why we need to move to season based governance.

00:07:45

Thank you. Seja. Before we move to SA solutions, our software lifecycle governance looked like this. Our traditional development process focused around annual releases with quarterly minor releases and hot fixes as needed. We used a stage gateway of working with a formal ceremony between the stages release approvals required, a ceremony to be held. I included all stakeholders. This worked well because the delivery cycle, our clients and our technology needs were different. Then our clients need stable baselines that they can make comparisons between different scenarios or studies, which can be developed over a long period of time. This meant though the governance and releases were coupled in 2016. As we moved to the cloud, this traditional approach did not work. We needed to deploy and release at a fast rate. It is impractical to hold a stakeholder ceremony for each deployment. We needed a new governance strategy fit for cloud development. In fact, we needed a major refresh as we needed to incorporate other improvements, too.

00:08:52

The key principles we needed to incorporate were much more business agility, incorporating lean practices that had been used successfully elsewhere, a custom obsession with customer feedback, being incorporated from the start through to operating any feature we needed to embrace DevOps and particularly the whole ops piece when collaborating across many more boundaries for both inputs into what is developed, but also on building and operating any service. We now needed to gather and learn from many more data points from both our customers directly and on tracking how the services are working. The process was built on a large set of checks, document generation and formal signoffs. That's a grown up over time. We wanted to reduce this to an essential checks only and focus on communicating the vision and allowing the teams the flexibility on how to achieve it. We wanted to move away from projects to a service model where we develop and deploy a continuous stream of value with the stage gauge approach.

00:09:57

We spent a lot of time in detail planning and estimating work far out into the future, which locked in decisions and assumptions taken as commitments by stakeholders. Some of this work had to subsequently be thrown away. As new facts emerged. We wanted to adopt hypothesis driven development where ideas were tested as early and as cheaply as possible. And getting the customers involved from the start and pivoting upon the findings as mentioned, the detail plans were built, signed off and stored in the doc store, perhaps with sun never to be referenced again, we wanted to move to a live documentation, add more collaborative ways of working by having regular sync meetings with the relevant parties and only critical artifacts being reviewed and signed off. Having a live ceremony for each deployment was impractical. This is probably the most critical change in the governance needed to decouple from releasing the team needed to be trusted, to deploy and to release or progressively reveal features saved by the use of feature flags and reviewing progress regularly with business, the annual release cycle and limited or no access to any telemetry at all had fostered a culture of generating lists of features to develop.

00:11:16

I E an output centric way of working. We needed to move to an outcome based way of working by focusing and learning from how customers react, any change or idea with many more roles now involved in building and operating a service. We needed to work against the silos and handovers forming, which caused the progression of work to slow with the annual release model compliance checks were completed before each release, but now compliance starts on day zero and is continuous thereafter a dramatic shift in the way of working suya. Tell us about S SPG and how it's addresses these needs.

00:11:57

So season based governance is a new way of working for software teams. S SPG is designed to deliver value quickly and safely. And as a parament shift in the way we plan, for example, our typical product teams are spread between multiple centers, a Houston Oslo, Beijing. They work together to deliver software, to solve a particular challenge. They uses SPG for their planning. They deliver new features every two to three weeks and have a fast cadence in their planning. So they can respond to feedback and opportunities quickly. They strive for higher alignment and autonomy to ensure they have flow and deliver value. So how does SBG work? The planning is broken down as follows vision lasting 12 to 18 months, seasons lasting three to six months, sinks lasting three sprints and sprints lasting two to three weeks. Let's start with the vision. The vision is external facing and defines.

00:12:49

What we would say is the future state of the organization. It looks at what strategic goals will lead us to the vision. It is where a well aligned investment should lead us underneath. We use a business model canvas to help define the vision. The vision owner would present the vision to the entire community every 12 to 18 months. Our product vision is visible to anyone in the company. Yes, a vision is important, but if it's too high level, it is hard to know how one's work contributes to its the vision. And this is why we have the value tree. The goal owner takes the high level vision and builds the lean value tree. We use hypothesis driven development, and we define bets, which deliver a promise of value. The teams are responsible for executing a bet. The outcome of which will drive the next planning for product teams. This helps align the vision with the investments. Now let's talk about the season. The season represents the business governance cadence. It's typically three or six months, depending on the business needs. It is not a release cadence. So I've talked about different roles. So just wanted to mention that these roles, vision owners, goal owners, be owners and the team or tribe translate to standard engineering and business roles within the product teams.

00:14:03

Now in the value tree, you can see the line of autonomy, and this is key. Everything under the line is the team or tribe responsibility. So whether the tribe decides to use two week or three week sprints use scrum or can ban or any other agile methodology to deliver value, that's up to them. We don't govern how individual teams operate. The goal owners define and are accountable in how they deliver the goals. The goal owners workshop with the team and align with vision owners on a season cadence they're responsible in engaging with the end users and bringing the feedback continuously into the planning. The season plan is then presented at the all hand ceremony called the season finish season start. It is not a decision meeting, but an alignment meeting. This is significantly different to the heavy stage gate meetings that we had before that required the approval of many to move forward.

00:14:54

Also, most of our ceremonies are open to everyone in the community to attend. So what happens in a season, the product team will generally have different activities in different stages of maturities. Ideas can come from anywhere and at any time a customer need a market opportunity or an improvement using hypothesis driven development. We prioritize test and learn continuously before working on an MVP in the explore phase. And then it's rating until we decide to scale out, this is not a linear process in a typical season, you will find activities in early ideation, some being prototyped, some in explore and some other workflows in scale out having been continuously validated and enabled for the end user. And we work and partner with our customers at every stage in the product life cycle. So in summary, what a team does in a season depends on the maturity of the investments, supporting the strategic goals.

00:15:48

So a couple of things I wanna highlight, we have a mix of as needed and calendar based meetings. Most are open to anyone to attend. Pivots from plans are lightweight and can happen at any time. Work streams may start and finish within or across seasons, as releases are not tied to the season, releases are continuous. And as a product matures through explore to go life, we have appropriate governance which is needed as needed and not dictated by a calendar cadence seasoned workshops happen just before a season start. And these are when teams review feedback opportunities and learnings, and use that to align with dependencies and stakeholders and plan for the next season. It is not a single meeting. It is more a period of time and regular syncs enable a continuous alignment with external dependencies syncs also drive a shift left mindset for security, operational readiness, you know, defining and instrumenting LIS as low as SLS. For example, running disaster recovery drills, et cetera. This allows teams to push code to production continuously, safely and securely with minimum manual checks. So that's S SPG in a nutshell, by the way, we didn't get any of this, right. The first time round S SPG itself has had many, many iteration and continues to evolve as we learn from our teams. So Nigel, can you tell us how we continue and grow?

00:17:11

Thanks UJA. We wanted to improve our software delivery and operational performance. So we adopted Dora from the DevOps research and assessment team. Now part of Google, this is characterized by the four key door metrics, covering throughput and stability of DevOps operations. These are lead time for changes, deployment, frequencies, change, failure rate, and time to restore service plus a measure for operational performance. It is important to read the state of the DevOps report for the Dora definitions of these to positively impact these metrics. The Doris system takes a holistic view and recommends improving a broad, broad set of capabilities, covering technical practices, process measurements. Yes, and culture. Two, focusing on these capabilities has been statistically, uh, proven to improve the four door metrics and to positively impact all stakeholders, including the customers, the company, and the staff. Most metrics used in the industry are used because they make logical sense around which a narrative can be formed and communicated, but actually have no solid statistical basis that justifies investing in them.

00:18:20

The Dora system does have solid statistical basis. Hence why it attracted us in order to help the product teams determine which capability improvements have the best R R R ROI for their context and should be invested in next, we conducted with Google's help door assessments, the results of which fostered excellent whole team conversations on capability improvements. And the teams have divided hundreds of capability improvement plans. Many of which have been implemented are more implement, were being implemented every day. We can see that our continuous improvement processes positively impacting our software delivery and operational performance. We're absolutely delighted that Sunjay was recently awarded a Google cloud DevOps award for our DevOps transformation. It is great to see the whole of the software team at slum Berger being recognized for their awesome achievements. And we're really proud of them all here is our vision, which is to enable our product teams to develop capabilities securely and to help our product teams, to constantly discover value through techniques such as UX practices, customer engagement, et cetera, and to build and scale out others build and scale out significant value.

00:19:35

We have also transformed how our teams learn, including complementing role based learning with product based, learning by including coaching and training to address product team needs. We have built a dashboarding system that pulls information from many sources to give a single place for product teams to review their health and quality for their products. We have built SBG product Wiki page templates, which the product teams use to record key product information. These pages are versioned and have access controls, but we can't rest here. We have more to do. We started with these four core broad areas and are continuously incorporating more areas into the governance system, including customer experience, EG sentiment analysis, product management, and innovation, and how to enable it. The governance is not a static thing, like say a maturity model, but it's constantly evolving living system. We gather feedback from the product and service teams on heritage operating.

00:20:41

Yes, they're our customers and monitor industry trends. So to the challenges, we're working hard to build seamless integration across all the roles involved in cloud based development, but we are a large organization. So this takes a lot of work. We have built SBG whilst digitally transforming, which means constantly iterating, growing and evolving what is needed and learning from experiences. The first versions of SBG assumed that we deployed to a single cloud vendor, but our products are deploying to multiple cloud vendors. Hence we needed to work out which tasks needed to be repeated to onboard a second vendor for a service. And what does not, the traditional development model had been used for a decade or more. So there is much institutional unlearning that needed to take place in order to fully onboard. The new ways of working. Some of this includes moving away from outputs, say list to features, to talking about positively impacting customer behaviors.

00:21:42

We have always had customer involvement and collaborations in our development process, but we want to have more and we want to engage earlier. Our customer's time is very precious. So we have to find ways to fruitfully engage with them. We have found that ending a season at the year end cause the crunch due to clashing with a key vacation season and financial year end, we recommended that teams, uh, ended their season in January instead, which the teams have found a very positive move here though. We've only brushed the surface of our governance system. And we'd love to hear more about what you think about it and what is missing software governance is not a commonly discussed topic, but everybody has one. So we're really interested to hear how you do governance and what principles and philosophies are important to you. So you've heard from us, but let's hear from our users.

00:22:37

Hi everyone. My name is Dan Hal. I am the head of products for Delph. Delph is our flagship SA offering. It's a commercial offering from Stromberg. Obviously we could not have delivered Delphi without the agility and lean product management that SBG enables for our teams while still delivering reliable and secure solutions for our customers.

00:23:00

Seasons based governance has liberated teams from the previous process model, which was relatively onerous in terms of documentation and checkpoint reviews. SBG provides teams with an appropriate blend of control and flexibility, and it supports both our agile and user center design working practices.

00:23:22

Thank you for Danny and Matt on sharing their thoughts on SBG. As mentioned, we gather inspiration and ideas from both internal and external sources. We would like to thank all our technology partners and all those in the digital technology community at Schlumberger for their hard work, developing iterating, and maturing this system. This is a work in progress and we are constantly striving to learn more and adapt SBG. Also thank you for your time today for listening to this talk, we're looking forward to hearing from you in the slack channels. After this session, you can also reach us via LinkedIn, hear our QR codes for our profiles. Thank you and enjoy the rest of the conference.

00:24:03

Thank you. Thank you for listening and look forward to hearing from you.