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 master training in Bangalore 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.
Resource: https://www.scrum.org/resources/blog/using-scrum-improving-operations
0 comments:
Post a Comment