Mastering Complexity in Scrum: Transform Your Team with Agile Product Strategy Insights

Published on
3 minute read

In my journey through the world of Agile and Scrum, one of the most enlightening experiences has been teaching the Agile Product Strategy (APS) class to beginner Scrum teams. The most valuable takeaway for these teams is undoubtedly the grounding in understanding complexity and empiricism. Today, I want to share my insights on why these concepts are crucial and how they can transform your approach to Scrum.

Understanding Complexity

Complexity is a fascinating topic, especially when we consider how it impacts our planning and execution. As we delve deeper into complex environments, we often find ourselves on an exponential scale of unpredictability. Here’s how I see it:

  • Low Complexity: In scenarios where complexity is minimal—think of a textile mill with a thousand machines producing fabric—we can plan with a high degree of accuracy. We understand the cadence of the machines, the time it takes to retool for different fabrics, and the overall workflow. Variance is low, and while surprises like machine breakdowns or injuries can occur, they are relatively infrequent.

  • High Complexity: As we transition into high variance work, the landscape changes dramatically. This is where the APS class shines, focusing on quantifying what high variance work looks like and how it feels for those involved.

To illustrate this, we often engage in experiential exercises. Depending on the class, we might build websites or even use Minecraft—my personal favourite! This hands-on approach allows participants to truly feel the difference between complicated and complex systems. Once they grasp this distinction, we can pivot to discussing risk mitigation in complex environments.

The Importance of Transparency, Inspection, and Adaptation

In the realm of complexity, the principles of transparency, inspection, and adaptation become paramount. Here’s why:

  • Transparency: We emphasise the need for clear visibility into our work. The definition of done, the product backlog, and the Sprint backlog must all be transparent. Without this clarity, the value of our Scrum events diminishes significantly.

  • Inspection: There’s little point in conducting a Sprint review if we don’t have a transparent product to evaluate. Similarly, Sprint planning becomes ineffective without a clear product backlog. These artifacts are the foundation upon which everything else is built.

  • Adaptation: The ability to adapt based on what we learn during inspections is crucial. It’s this cycle of transparency, inspection, and adaptation that enables teams to navigate the complexities of their work effectively.

Conclusion

As I reflect on my experiences teaching the APS class, I am continually reminded of the profound impact that understanding complexity can have on a Scrum team’s effectiveness. By embracing these principles, teams can not only improve their processes but also foster a culture of collaboration and continuous improvement.

If you’re interested in exploring these concepts further or have any questions about Agile, Scrum, or DevOps, I invite you to book a coffee chat with me through Naked Agility. Let’s dive deeper into how we can enhance your Scrum journey together!

Thank you for reading, and if you found this post helpful, please like, follow, and subscribe for more insights. I always appreciate your comments and look forward to our discussions!

So the most useful element of the APS class for beginner Scrum teams is really that grounding in understanding complexity and empiricism. Right, um, so that’s something that we really focus on and double down on those two things. So the first one is complexity, right?

There is a difference as you increase in complexity, and usually it’s an exponential scale, right? The type of processes and practices that you use need to change as you increase in complexity. So if we have very low complexity, um, let’s say it’s just complicated or even it’s simple, then we can probably plan further out into the future and be okay. Right? We can plan, let’s say we’re running a textile mill and we have a thousand machines producing fabric. Um, in general, you’ll be able to predict how long to a very high degree of accuracy it will take to fulfil whatever order comes in, right? Because you understand the cadence of the machines, you understand how long it takes to retool the machines for different types of fabrics or different patterns. You already understand all of that stuff up front, and it’s fairly consistent.

There’s the odd thing: a machine breaks down, something else goes wrong, somebody gets injured, right? These are all things that can surprise you or get in the way, but generally the variance is very small. As soon as you get into really high variance work, the APS really focuses on that piece, that high variance work, and quantifies what does it look like and how does it feel, right? How does it feel for the people involved?

Um, so we do that through an exercise that enables people to experience complexity. Depending on which class you go to will depend on what experience that is. Uh, we’ve done building websites, uh, we’ve done Minecraft, right? That’s my favourite one, is using Minecraft in that class, um, to create that complexity so that people actually feel it. Once they realise the difference between complicated and complex, they feel it. Then we can start talking about, well, how do we mitigate risk in that world of complexity?

And that’s where we focus very heavily on transparency, inspection, and adaption, right? That’s why we talk about the definition of done really heavily. We talk about the product backlog and why it needs to be transparent. Um, we talk about the Sprint backlog and why it needs to be transparent. All of those things are the important piece because everything else is built on top of it.

There’s no point in doing a Sprint review unless you have a transparent product to look at. There’s no point in doing a Sprint planning unless you have a transparent product backlog to look at. You need those, um, artifacts, those three artifacts in Scrum with their commitments in order to be able to do everything else, and that’s what makes it valuable.

Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.

Transparency People and Process Scrum Product Development Agile Product Management Agile Planning Complexity Thinking Agile Project Management Agile Transformation Transparency and Accountability Professional Scrum

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients​

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.​

Emerson Process Management Logo
Slicedbread Logo
SuperControl Logo
Lean SA Logo
Workday Logo
Hubtel Ghana Logo
Philips Logo
Bistech Logo
Illumina Logo
Xceptor - Process and Data Automation Logo
Capita Secure Information Solutions Ltd Logo
Brandes Investment Partners L.P. Logo
New Signature Logo
Healthgrades Logo
Trayport Logo
ProgramUtvikling Logo
Big Data for Humans Logo

CR2

Royal Air Force Logo
Washington Department of Enterprise Services Logo
Nottingham County Council Logo
Washington Department of Transport Logo
Department of Work and Pensions (UK) Logo
New Hampshire Supreme Court Logo
Healthgrades Logo
DFDS Logo
Slicedbread Logo
Genus Breeding Ltd Logo
Akaditi Logo
Epic Games Logo