I'm encountering more and more people that are trying to solve different kind of problems with Scrum:
- People designing Consumer Goods
- Accounting professionals focused on Revenue Accounting
- Marketers of many kinds
- Healthcare professionals.
I've been having some interesting discussions with them that I thought I might share.
One of the key questions I start a conversation about Scrum with is Why - Why do we need Scrum? What problems are we looking to solve with it?
Next, we typically explore Where/When - Where would it make sense to use Scrum? When would it or wouldn't it?
One thing to remember is that Scrum was designed to help people solve complex problems, not all sorts of problems. What does this mean exactly?
Let's look at a couple of examples of Complicated processes that might not need Scrum/Agile
Accounting teams run several sorts of processes - like Closing (the month, quarter, year), Reporting, Accounts Payable, Accounts Receivable.
Healthcare professionals treat patients. Whether it is an emergency room, an orthopedics clinic, or a covid19 testing provider.
Should we use Scrum for Operational Processes?
These might be complicated processes but they aren't typically complex. Lots of steps, lots of work they need to be careful and diligent about, but it's not something they need Agile for on an ongoing basis.
Hopefully, these operational processes are stable and predictable. If they're not, we have some work to do. We need to get rid of variability and surprises.
We can use Scrum for Improving operational processes
Where Scrum IS often useful is in the process of continuously improving these operational processes. We know how to run the current process predictably. But once we decide to improve it, this might be a problem we have more uncertainty about - what does better look like? What will/won't work? How do we go about implementing it?
What we find in many contexts is that people call these improvements "Projects" and its one of the areas they struggle with. Beyond the classic challenges of complex work, we see many cases of teams working on improvement projects that are based on people who also work in the operation. (for example an A/R professional working on a project to improve A/R or a physician participating in a project to implement electronic medical records software). These teams working on improvement "projects" struggle to focus. As we all know, Allocating capacity to improvement is hard. And switching contexts between the day-to-day operation and improvement work is hard as well.
Scrum helps these teams optimize the value they create through their improvement work.
Their "Product" is an improved operation that achieves better outcomes for their stakeholders while making life easier for themselves and their peers.
We want the entire company to be Agile
We're hearing that more and more aren't we?
As you can imagine based on the above, I'm of the opinion that we need to be careful and apply the right tool in the right context. Agile approaches make sense in many contexts and most companies would indeed benefit from applying them beyond software development/technology/IT.
Identifying the different "Operational" flows in the organization and the various "Development/Improvement" activities that work to improve them is a great way to drive a discussion with a company or a leader that is exploring Agile/Scrum all over the company.
In Summary - Scrum for Improving Operations, not necessarily Scrum for Operations
This distinction between the ongoing "Operations" where we don't necessarily need Scrum or Agile and "Development" or "Improvement" work that aims to improve "Operations" helps people outside of software/technology/IT relate and buy-in to Scrum or other Agile approaches.
PS You might find it interesting to read about "Operational Value Streams" and "Development Value Streams" in SAFe, which are similar concepts to what I'm describing here.