Scrum and Non Software applications

I come from an Oil and Gas exploration background, where the business model for Oil exploration was Agile long before the software industry existed. To explain - when you are given a field to explore and develop, you have little information and idea what you are going to find. You drill the first few wells knowing that you will never produce any oil or gas from them - purely for information and exploration before you get a cent of money to develop the field. And you keep doing this, inspecting and adapting both for geological information (3D mapping, seismic etc) and for understanding the complicated mechanics of the rocks and how to safely drill them. The Plans are typically flexible lasting over decades of project life, going this way trying to maximize benefit. 

I'm not sure that really represents an agile way-of-working, because empirical process control only becomes possible once field development begins. Rather, hydrocarbon exploration constitutes a leap-of-faith which oil companies take when dealing with governments and/or their NOCs. The opportunity is only there to inspect and adapt the process of discovery itself, based on real-time survey results.

Also, the bidding process to get to production is not always transparent. Governments request bids, usually with minimum work programs (fixed scope and perhaps time), for which they issue licenses or contracts to companies for certain geographical blocks. Companies may be expected to improve their bids with a "signature bonus" that a government will pocket, should the bid be successful, and preparatory lobbying can take years of speculative investment. All of this adds to the sunk costs of development. I don't care to speculate what sort of political shenanigans might go on behind the scenes before oil flows. But as a purely engineering matter, I suppose you have a cycle time of going from the first exploration spud to the total depth for production and sales. That's nothing like a feedback loop which can be closed in an agile timescale.

A better application of Scrum might be found in oil production itself, and platform decommissioning. Anything to do with maintenance, the reduction of downtime due to equipment failure or human error, and risk mitigation, is likely to benefit from lean and agile discipline. From what I've seen of it, sustaining a jacketed rig in the North Sea is beyond complicated, each one being special in some way, and is really more of a complex domain. Scrum Teams are certainly being used.

Thanks for the reply. My example of oil exploration involving iterative cycles of inspect and adapt was meant to start a conversation why so much of the theory practices involving Agile is centered in Software development when project management across all fields are evolving. Its like having the a great accounting standards and practices but its only designed and taught in Banking. Yes, agile practices could very well be used in production, maintenance and other functional areas of the business, Kanban is gaining popularity. These ideas originally came from manufacturing and based on culture and work practices. Many companies in the Energy business are experimenting with Scrum and Agile across their businesses and are achieving some success. Exploration, Production, Downstream, Upstream etc. The certification at Scrum.org tend to presume that you are in the business of software while it is openly admitted that Scrum is applicable almost anywhere the work is complex and hard to predict. I fear taking exams at a high level because it presumes your experience is in software development. 

... it is openly admitted that Scrum is applicable almost anywhere the work is complex and hard to predict. I fear taking exams at a high level because it presumes your experience is in software development.

Even in software development, people take issue with Scrum because they believe their situation to be unique. The framework is widely dismissed as being too “vanilla” or too “generic”. I’ve often heard it argued, just within IT, that professional Scrum and its assessments must surely relate to some other context.

My advice would be to review the Scrum Guide. Consider whether the roles, events, artifacts and rules are inapplicable, or highlight the need for organizational change when building products that are, as you say, complex and hard to predict.

Scrum is a great framework when you are in a complex situation, where you can formulate a small goal that you can plan towards for a few weeks.

But what is complex? To answer this question, I like using the Cynefin framework,

The Complex area is where you are dealing with unknown unknowns. Basically you are aware that you are probably missing information, but you don't know what you are missing just yet. This is where you experiment to try and find the variables in the equasion. 

Many people think they are in a Complex situation, but are actually in the Complicated area. This is where the known unknowns are.

I think maybe for the oil example this could be the case. You know you have to drill to prove there is oil and get funding, but you don't know exactly where to drill. The Complicated area is where you need analysts, who are capable to calculate the most likely outcome and apply a good practice. An oil company doesn't just randomly start drilling in someone's back yard, there are people who can make educated guesses, based on satellite info, complicated models, etc.

There is also the Obvious area, where you can just look at a problem, categorise it and just follow the regular procedure. If A and B apply, then do C.

The fourth area is Chaos, where you really don't know what you need to be doing. Startup companies and new teams begin here. They come in, don't know who their customer is yet, don't know what product to develop and don't know the value they are delivering. Lean Startup would be a good approach here.

While Scrum is very suitable for the Complex area, it is not so much in the Complicated and Obvious areas. You don't experiment when you can analyse or categorise the situation.

This is also why some software development teams are struggling with Scrum. A lot of work that is done in software development is not Complex, but Complicated or even Obvious.

Obvious work in software development can be deploying a new release to a server, monitoring code quality or running the automated tests when you change a bit of code. Basically all the straight-forward stuff that you can automate. 

Complicated work can be deciding which regression tests to run when you change a bit of code, applying architectural guidelines and migrating to a new version of the database. These are the things you can analyse up front, make a decision and apply what was decided. Waterfall works well here.

Complex work would be story finding, designing new features, defining acceptance criteria and setting up a CI/CD pipeline from scratch. You have an idea of what you want to achieve, but can't be sure that you are doing the right thing.

Teams that are mostly in Complex are well off using Scrum. Teams that are working in an Obvious or Complicated context are better off using Kanban or waterfall. If a team is in a mixed situation, so half he time in Complex and half the time in Obvious or Complicated, they may find Scrum with Kanban useful.

At all times, be mindful of your current context and how it changes over time. If needed, adapt and reorganise yourself accordingly.

For more info, see https://en.wikipedia.org/wiki/Cynefin_framework