The Sad Venn Diagram of Agile Practise
TL;DR
Many people and organisations are already on the agile bandwagon, and more want to do it. But it’s ever more a buzzword and a brand. The biggest problem with Agile is that few people are set up to succeed in Agile practice. Why? Because the focus is all on the agile narrative and not on the enabling factors that allow agile to grow. At least seven (7) factors need to be in place for agile to succeed. Or if not “in place”, then at least acknowledged and understood so the individuals, teams and organisations can actively evolve towards better capabilities. This situation can be shown in what I call the “Sad Venn Diagram of Agile Practice” — sad because so few people are “agile ready” or even “agile capable, and this often doesn’t end well. But there are opportunities for a successful journey to good agile practice if you take the correct route.
A form of this story was originally published in my book “Adam On Projects: 101 Axioms on the Art and Science of Managing Projects of All Kinds” under the axiom: “Just because you want to do agile doesn’t mean you can or should do it.”.
Why do people want to do Agile?
Why do people want to do agile? And is everyone who “wants” to be an agile practitioner ready to be successful?
Jeff Sutherland described the ability to get teams into a state of “Hyper-productivity” and claimed substantial improvements, as shown in my selected quotes below:
“… shows an annual Return on Investment (ROI) of 1000% for investment in Scrum trainers ... achieved an average productivity increase of 666% …twice the work in half the time …” — Jeff Sutherland in “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework” 2011
Who wouldn’t want those results?
I prefer to call this state “Hyper-performance” because productivity — in my mind — is a measure of other things and largely ignores human well-being and safety. Hyper-performing teams, in my opinion, must also be sustainable teams.
Sadly, it seems that many people — and organisations — want to do agile for spurious reasons: “it’s better”, say some, or “everyone is doing it”, say others.
Will everyone be successful? No way, Jose!
Your agile journey won’t work if you don’t have the right enablers in place or even know they are part of “being agile”. Even worse, you may think that studying and practising agile techniques will automatically bring those enablers into existence.
Unfortunately, this is not the case.
Agile Enabling Factors
What enables good Agile practice? Let’s assume that the “desire to do agile” is a given, whether intrinsic or forced.
After that, there are at least seven factors that you must identify as enablers to successful practice before we think of the Agile Manifesto or any agile-specific training. These are:
- Environment Complexity (Cynefin)
- Organisational Affinity (Westrum’s Organisational Topologies)
- Dominant Mental Paradigm (Paradigm Zero)
- Personal / Psychological Development (Kegan’s Development Model)
- Agency — Individual and Team (Bandura’s Emergent Interactive Agency Model)
- Customer Enablement Construct (Norman’s Second-level relationship)
- Domain Expertise Depth and Breadth (Skills Shape)
- Agile Knowledge & Skills
At the intersection of all these factors is a zone I call the “Agile Hyper-Performance Zone”, in which teams have the potential to achieve the promise of agile.
I have developed a conceptual model of how these factors interact and accumulate in this yarn by showing them as different two-dimensional spaces in a Venn diagram. As we overlay the different spaces, these factors affect and show you how the agile zone of high performance reduces as I layer in additional factors.
Think of this as an ecological study in which we map all the factors that a particular species — Hyper-performant Agile teams — need to survive and thrive. The intersection — where all the factors exist sufficiently to sustain the team — is the habitat within which the team can thrive.
The Agile Project Landscape
As a starting point, let’s map out the theoretical space within which all goal-based initiatives live. Call them “projects” or “programs or whatever. This includes all types of approaches to initiatives, including Predictive (aka plan-based or Waterfall), Iterative, Incremental, Adaptive, or just the methodology people that people “use around here”.
Now we add the space within which people “doing agile” operate.
I’ve made this about half; maybe it’s bigger or smaller. I don’t know if we have reliable penetration analysis for Agile, but it’s a fairly big chunk.
Now let’s layer in the first of our enabling factors.
1. Environment Complexity (Snowden’s Cynefin Model)
The first factor is the complexity of the project environment: is it reasonably stable or chaotic?
We can assess the environment’s stability using Cynefin domain analysis.
Agile works best in environments that are either “Complex” or “Chaotic”, in which problems are ill-defined, and there is no clear cause-and-effect relationship, or there is no clear understanding of the problem or how to solve it. Agile is best for domains that are not stable, where required information is both unknown and unknowable (at least timing-wise).
Other project models are better if everything is stable, predictable and known.
This restriction may appear to limit the applicability of Agile. But is our environment intrinsically complex, or are we making it so? We often make things seem more complex than they are.
So we overlay the “space” within which environments are Complex or Chaotic. Of course, this overlay shows the Complexity space covering agile projects, other types of projects, and other work outside the project space.
The intersection of the Complexity space with the “Doing Agile” space produces a subset where agile is potentially enabled. Let’s call this our “Agile Performance Zone”.
2. Organisational Affinity (Westrum’s Cultural Topologies)
The second factor relates to the organisation that “hosts” the project. Does the initiative’s hosting organisation support and encourage agile behaviour?
Westrum’s Cultural Topologies model is a good fit for assessing agile affinity. In the Westrum model, for agile to succeed, we need a “Generative” culture or, at the very least, a “Bureaucratic” topology that supports individual and team agency, which is also essential to agile success (see the fifth enabler below).
We can see the “Agile Performance Zone” has reduced rather dramatically already.
The next two enablers relate to how people think about the world and interact with other people.
3. Dominant Mental Paradigm (Paradigm Zero)
How people see reality and the knowledge required for projects. This factor is based on classical philosophical concepts but adapted to projects.
There is a fundamental dichotomy in the human brain when thinking about reality and knowledge that has been philosophised for two millennia.
I’ve adapted this (and simplified it) for projects. I call it “Paradigm Zero”.
- “Hard” Paradigm Zero thinkers see reality as fixed and independent of context and believe knowledge is obtained through reason alone.
- “Soft” Paradigm Zero thinkers view reality as changing with context and believe knowledge is obtained through the senses.
This factor is important because it affects how people approach problem-solving and decision-making. “Hard” thinkers tend to think in terms of a single correct (“perfect”) solution, whereas “Soft” thinkers can deal with multiple possible solutions and value context and co-creation.
Without a “Soft” Paradigm Zero, it will be very difficult for Agile to survive and thrive since it is so dependent on positive interactions among team members and stakeholders.
The “Agile Performance Zone” reduces again.
4. Personal / Psychological Development (Kegan’s Psychological Development)
The fourth enabler relates to people’s emotional and psychological development.
I use a model and a scale developed by Robert Kegan, who divided emotional development into six stages.
For agile to work, people must be at Stage 4 or a mature Stage 3. Otherwise, they cannot relate to others in a way that “puts themselves in the other person’s shoes”.
Kegan described Stage 4 as comprising only 35% of the general population, although it is unclear how that relates to the population of people who want to be agile. I am investigating appropriate measurements and assessment tools that may help determine stage levels in a small team.
And again, we can see the “Agile Performance Zone” reducing.
5. Agency — Individual and Team (Bandura’s Emergent Interactive Agency)
The fifth enabler is the ability of people and teams to act and choose, to take responsibility and reflectively make progress.
This ability is called “Agency” and is the engine of any project.
High levels of Agency give projects energy and forward momentum, allowing team members to prosecute the project’s objectives actively. Its absence results in a project that loses its way. Through their Agency, people take responsibility to collaborate with other stakeholders, align their actions with the project’s objectives, and adjust their performance to converge on agreed quality.
High Agency is related to emotional development but is distinct. I am investigating appropriate measurements and assessment tools that may help determine stage levels in a small team.
But we can identify a set of desired characteristics from Albert Bandura’s theory.
Bandura believes people are not just reactive organisms shaped and guided by external events. Instead, people can influence their actions to produce specific results. He describes ‘reciprocal causation’ in which people are both the shapers of social systems and being shaped by them.
In Bandura’s “Emergent Interactive Agency”, people have four agentic behaviours, in that they can be:
- Self-organising: by shaping and directing their actions towards a goal
- Proactive: by taking the initiative and not being dependent on external triggers or forces to take action
- Self-regulating: by controlling their thoughts, motivation, and action
- Self-reflecting: examining their place and performance and making changes.
All of these can operate at both an individual and group level.
6. Customer Enablement Construct (Normann’s Second-level Relationship)
The sixth enabler is how the people/teams in the project understand the value construct and the relationship between the project and the customer. A key factor is customer empathy: the ability to sit inside a customer’s head and understand what they do and how they create value for themselves. This ability is enabled in part by broad experience and mature emotional development. Customer empathy is a particular skill that requires people to suppress their focus on their team and the technologies they are working with and instead think like a customer. Many organisations and people pay lip service to this ability, but doing it is rare.
I wrote a piece a while back that described two ways to assess this capability:
- Kathy Sierra’s “Amazon Book Review” assessment.
- Normann’s Second-level relationship model.
Please, refer to my yarn: “This powerful brain hack helps you think like a wildly successful founder”, for more information on value-based mindsets and the Second-level relationship.
7. Domain Expertise Depth and Breadth (Skills Shape)
The seventh enabler is the team members' general experience and skill level across a broad range of subjects.
I mean not just software development (or whatever domain covers the things being built) or Agile topics and techniques.
We need diverse, strong, collaborative and cross-functional teams in Agile. This means we need everyone to be “roundly developed” with knowledge of other topics, such as history and human psychology, skills in a hobby, a broad understanding of global cultures and societies, law and humanities.
An analogy for this enabler is the various letter-based skill types, such as T-Shaped, Pi-Shaped and “Comb-shaped”.
In these models, the cross-bar of the shape (e.g. the top of the “T”) represents the breadth of the skill base in an individual. The downward legs represent the depth of the skill.
For agile, “Comb-shaped” skills profiles are required, but extremely long combs. Think of a long white picket fence. Or the “Rabbit-Proof Fence” in Australia’s outback.
Summary
For each of these enablers/factors, we must go beyond simplistic and generic terminology, e.g. “Collaboration” or “Courage”, which are prevalent in the agile narrative. We must frame specific target behaviours and capabilities to be more actionable.
Wait! What about Agile Skills and Knowledge
Hopefully, you noticed I hadn’t included anything about Agile skills or knowledge as an enabler of agile hyper-performance. That was deliberate for two reasons:
- I couldn’t put Agile skills & knowledge any higher than #8 on the critical enablers to agile success list.
- If you get these first seven right, you’ve probably covered 90% of the critical knowledge you need. You’re probably doing agile already, even if you don’t label it that way.
Don’t worry too much about learning agile if you want to do agile well.
The Agile Zone of Potential Hyper-Performance
That little red blob at the intersection of all those factors is the ecosystem within which Agile practice can thrive. I call this the zone “Potential” because, even with all these factors in place, there is no guarantee it will happen.
The Bottom Line
I call this the “Sad” Venn diagram because the potential for successful agile practice seems minuscule. But given how much bad agile practice you see, does it not resonate?
Don’t be disheartened!
The reality is that very few organisations where agile is practised have all those enablers. The most important thing — and this goes to the heart of the agile mindset — is that these seven factors are at least visible to the participants: (aspiring) practitioners, coaches and managers. For example, Kegan describes ways organisations can help their employees’ growth pathways, for example, by establishing “safe spaces”.
Everyone has to start somewhere, and we must be optimistic to believe we can evolve to that Hyper-performance Zone over time.
But it isn’t a given, and it isn’t going to come from a 2-day CSM course or the equivalent.