How to Un-suck Methods and Frameworks
Level 1: Getting Ready for Team Improvement
Most methods and frameworks suck as change programs.
They are collections of good ideas, offered in terrible packaging.
But I have a suggestion how we can un-suck the frameworks.
Let’s assume you are forming, leading, or coaching a team. You want to do something together. You want to have high performance and enjoy great achievements.
Where do you start?
I know many people working in badly performing teams that produce mediocre results. Some of them hope to improve their teams with the help of methods and frameworks. But these models always show you a static picture of a bunch of practices. As if there is such a thing as a “ready state” in organizations! (Hint: there isn’t.) But none of those models take into account how people change.
The Science of Change
Shouldn’t how people change be the starting point?
Shouldn’t validating forward movement be the first thing to achieve?
Why bother painting a total picture when people can’t manage to make even a single step?
It’s ironic that agile frameworks show us a complete backlog with untested, must-have requirements for organizational change.
Here are five things I learned about change:
- People change behaviors in small steps by building tiny habits. It won’t work if you ask them to start something big. Instead, start small, habitualize, and grow from there. (See: Mini Habits, Stephen Guise)
- To stay in flow, each change should be somewhat challenging and require just a bit more skill. But when the increase in challenge and required skill don’t match, people get either anxious or bored. (See: Flow, Mihaly Csikszentmihalyi)
- Positive change correlates with happiness, and sustainable happiness is achieved with continuous daily progress, not with a one-time transformation. (See: The Happiness Advantage, Shawn Achor)
- Each desired behavior should make the person’s life either more convenient or more gratifying. Without this motivation, the behavior won’t stick. (See: Hooked, Nir Eyal)
- People choose irrationally. This means, for example, that they prefer limited options and decisions because having too many options is confusing and may lead to decision paralysis and decision fatigue. (See: Predictably Irrational)
In other words, if you have a team that needs improvement, what is most unlikely to work is: showing the team a framework that requires a big habitual change; or suggesting practices that are too challenging given their current skill levels; or focusing on a static future rather than daily progress; or making them feel they get an increased workload instead of convenience and gratification; or offering them too many options and decisions to choose from. With a combination of these mistakes, science suggests you have little chance of succeeding.
Most frameworks and methods ignore the science of change.
For example, this is what I found in the Introduction of Sociocracy 3.0, a model presented as “an open framework for evolving agile and resilient organizations”.
A driver can be understood in relation to the domain it defines and its relationship to other drivers. The driver that defines a domain is called the primary driver of that domain. The primary driver is the superdriver of all other drivers that arise as a consequence of people responding to it. A primary driver is itself a subdriver of its superdriver, except in the case of the organization itself, in which case it is referred to as the organizations primary driver. Two drivers existing as a direct consequence of a response to the same superdriver, are described as peer drivers. The prefixes primary, peer, sub- and super-, can refer to both drivers and domains.
I honestly love the ideas offered by Sociocracy 3.0. But I fear that most people will hang themselves after reading the Introduction. Or else they might die from decision paralysis when confronted with the framework’s library of 70 pattern descriptions. Too complicated. Too many options. People won’t change.
A second example is Liquid Organization, a method presented as “a new breed of organizational models, responding to the fast growing adaptability, engagement and collaboration needs within modern company structures.” Sounds awesome! But its makers offer this as an integrated model comprised of a dozen or more advanced practices that must be adopted in full. They claim:
These parts form a connected and working whole only if you implement all of it in your governance.
Liquid Organization offers great suggestions for modern, self-organizing teams. But apparently, the practices cannot be introduced in small, individual steps. And some are beyond even my comfort zone. And I’m the guy who is crazy enough to pay people without contracts.
The suggestion that the practices should be implemented together is like booking an adventure trip that includes bungee jumping, wild-water rafting, and skydiving. If this is too wild for me, it’s definitely too crazy for others. Too big. Too challenging. People won’t change.
As the third example, let’s look at the most famous framework of all: Scrum. The latest version of the official Scrum Guide ends with this note:
Scrum’s roles, artifacts, events, and rules are immutable and, although implementing only parts of Scrum is possible, the result is not Scrum.
Isn’t it strange that Scrum applies the pull principle when it comes to changing products (only pulling in the top items from the backlog when the team has capacity) but insists on applying the push principle when it comes to changing the team itself (pushing all practices on the team or else “it is not Scrum”)? Wouldn’t it make more sense to also apply the pull principle when changing the team’s behaviors, while specifically targeting increased convenience and gratification? Like, only pulling in the next practice when the previous one is Done and Validated? Like, “It works. We like it. Give us another one?”
I would prefer 20% of “pulled-in” Scrum that’s actually working over 100% of “pushed-in” Scrum that’s not working. And when we’re not allowed to call 20% of Scrum an implementation of Scrum, I can live with that. It is more important to me that the pulling, rather than pushing, of new behaviors into the team is much closer to the concepts of tiny habits, flow, happiness/motivation, and having limited options.
Some readers might say that “pulling in” Scrum practices is exactly what an Agile coach is supposed to do. But if that is indeed the case then the Scrum framework, as officially defined, simply doesn’t work. No small changes. No clear motivation. People won’t change.
A New Starting Point
Most methods and frameworks seem to get their starting point totally wrong. I don’t believe you can easily achieve change by showing people complicated models full of principles, practices, patterns, and incomprehensible terminology that together form an “integrated whole”. The frameworks contain many good ideas but they should be offered in a different way. Sociocracy 3.0, Liquid Organization, Scrum, Holacracy, the Spotify model, SAFe, Teal, and Management 3.0 are full of experience captured by experts. But the way those experiences are transferred to you should… improve.
Methods and frameworks offer great ideas in terrible packaging.
The first phase of any team improvement effort must be made simple. Very. Simple. It should be just a couple of steps that can be completed in a few hours of work. I am thinking of a triad of three topics:
- Who are we?
- What are we for?
- When do we talk?
The idea is that a successful completion of these steps results in a habit, is intrinsically rewarding, is still within every team’s comfort zone, makes their lives easier and gratifying, and keeps the available options to a minimum. Only after successfully completing this triad of steps will a team be given the next small batch of framework practices.
We could call this first level: Getting Ready for Team Improvement.
Who Are We?
One of the first things I did when I started my latest project was to give it a name: Agility Scales. After all, how can I talk about something, and store information about it, when it doesn’t have a name? Names are important because they offer a sense of identity. You can also consider logos, symbols, mascots, rituals, and other things. But in most situations, people start with a name.
Defining a team name is easy. But creating one that everyone agrees on can be hard. Are we the Service Team? Dev Team 404? Optimus Prime? Or The Golden Ball Dancers? (These are actual team names I heard recently.) You can use online team name generators, name association techniques, and other practices to form an identity. Most importantly, team naming is an activity that is highly relevant, creative, and engaging.
Surprisingly, none of the well-known methods and frameworks cover team names. Scrum? Nothing. Sociocracy 3.0? Nada. Liquid Organizations? Noppes. The models all focus on things such as decision-making, backlogs, and task boards. Important topics, for sure. But is it smart to ask teams to discuss complicated protocols and techniques when they cannot even agree on something a simple as their name?
Self-improvement is useless when you can’t define the self.
What Are We For?
The second thing to start with is a mission or purpose. What are we trying to do together? And who are we doing that for? You can use an About page, a mission statement, a slogan, a work expo, or the Ikigai model to discover and define your purpose as a team.
Again, most models completely ignore this topic. I searched for “purpose”, “vision” and “mission” across a number of framework documents and came up with nothing. I admit, a few at least mention the relevance of mission or purpose for teams, but they offer no concrete guidance on how to define it. At the same time, they spend page after page describing how to run decision-making meetings. But when teams cannot formulate their purpose, what is the point of teaching them how to make decisions? Decisions that will help them to achieve what, exactly?
If you don’t know where to go, there can be no movement forward.
I expect that purpose definition is for many teams the hardest of the three topics I am offering here. But it could also be the most fundamental. If a team can make this challenging step together, they should also be able to make all other steps after this. Purpose could be the litmus test for team collaboration.
When Do We Talk?
The last of the three is the easiest topic. When do we get together as a team, on a regular basis, to discuss what needs to be done so that we can achieve our purpose? Here you can think of practices such as daily stand-ups, weekly planning meetings, online discussion tools, corporate huddles, monthly meetups, and many more.
Most of the frameworks and methods cover this topic, and for good reasons. After all, decisions without discussions don’t make a lot of sense. The problem is, some of the models get carried away with their suggestions for productive meetings. It is no wonder that some people feel that frameworks are all about meetings.
It would be smart to start with the simplest possible meeting. Just agree on when and where the group will talk, on a regular basis. That’s all. Yes, there might arise a need for meeting facilitators, meeting setups, meeting protocols, and meeting notes. But not at the start. Don’t scare people off with documents full of useful meeting patterns. Think pull, not push.
Only open the toolbox when someone asks for more.
Level 1: Getting Ready for Team Improvement
That’s all there is to do at the first level of team improvement:
- Who are we?
- What are we for?
- When do we talk?
Your team should experiment with some practices that will help you get an answer to each of these three questions. Only when your team can complete this first level, it is ready for the second one, with slightly more challenging topics that will require just a little bit more skill. But if your team can’t even do this, why would you implement a framework?
The un-sucking of methods and frameworks starts with Getting Ready for Team Improvement. Turn the use of your name, your purpose, and your meetings into tiny habits. This may be challenging but doable. The results are certainly gratifying. And a To-Do list of three topics is manageable for everyone.
After several simple levels of team improvement, we will help you adopt the great ideas from Sociocracy 3.0, Liquid Organization, Scrum, Holacracy, the Spotify model, SAFe, Teal, Management 3.0, and more. But first, we need to validate that you are able to change.
Are you tired of methods and frameworks that suck?
But do you still want all the good ideas from those models?
Do you want to get ready for team improvement based on science?