AMIA#05 | Navigating Complexity: A Guide for Agile Teams (Part 2)
Aha! Moments in Agility
Live in your inbox every Sunday to help you build valuable software sooner
AMIA: #05
Reading Time: ~ 4 minutes
Hello. Welcome to the 10 new subscribers this week.
And… 52 new connections on LinkedIn.
Thanks for choosing to be part of the conversation.
In today’s email:
The story: Navigating Complexity: Part 2 - Leveraging Levels of Ignorance
Navigating Complexity: Part 2 - Leveraging Levels of Ignorance
Welcome back to the Navigating Complexity series. In part one, I discussed the Cynefin Framework and how it can help agile teams identify the domain in which they operate. In this article, I will explore how to leverage levels of ignorance to categorize requirements and apply the Cynefin Framework for effectiveness and efficiency.
I. Understanding Levels of Ignorance
Before I dive into the practical aspects, let's understand the concept of levels of ignorance. In this article, I will use the following 5 levels of ignorance:
Level 0 - everyone in the team understands and can do this work
Level 1 - Someone in the team understands and can do this work
Level 2 - Someone outside the team, but in the organization can do this work.
Level 3 - We can get expertise to help us understand and do this work.
Level 4 - No one has done this work before.
In agile development, levels of ignorance manifest in various ways. For example, a Level 0 requirement might be fixing a known bug, while a Level 4 requirement might be developing a new feature for a product with no precedent in the market. Understanding the level of ignorance of a problem is crucial to determine the appropriate domain and practices for addressing it.
II. Categorizing Requirements based on Levels of Ignorance
To categorize requirements based on levels of ignorance, you need to identify the level of expertise associated with them. For example, if everyone in the team understands and can do the work, it is a Level 0 requirement. On the other hand, if no one has done this work before, it is a Level 4 requirement.
Once you have categorized the requirements, you can apply the appropriate practices based on the Cynefin Framework. For example, for Level 0 requirements, you can use best practices, while for Level 4 requirements, you may need to use novel approaches and experimentation.
III. Applying the Cynefin Framework using Levels of Ignorance
To apply the Cynefin Framework using levels of ignorance, you need to determine the appropriate domain for the problem. For example, if the problem is a Level 0 requirement, it belongs to the clear domain, and you can use best practices. If the problem is a Level 4 requirement, it belongs to the complex domain, and you need to use novel approaches and experimentation.
In agile development, you can use the Cynefin Framework to manage complexity and make better decisions. By understanding the levels of ignorance and categorizing requirements accordingly, you can choose the appropriate domain and practices within the framework.
IV. Practical Tips for Agile Teams
Here are some practical tips for agile teams to leverage levels of ignorance:
Identify the level of expertise required for each requirement
Categorize requirements based on levels of ignorance
Use the Cynefin Framework to determine the appropriate domain and practices
V. Summary - TL’DR
In this article:
I explored how to leverage levels of ignorance to categorize requirements and apply the Cynefin Framework for effectiveness and efficiency.
By understanding the levels of ignorance and applying the appropriate practices based on the Cynefin Framework, agile teams can navigate complexity more effectively.
In Part 3:
Next week, I’ll show you how to apply design thinking to navigate complexity as an agile software development team.
When you’re ready…
I can help you in 3 ways:
Check out the resources list
Forecast timelines like a Pro in under 1 minute - Zero Estimate System
Fix the root cause of bugs & defects in your team - Root Cause Analysis Template
Book One on One coaching with me - Become a go-to Scrum Master in your organization.
Find me on LinkedIn and introduce yourself :)