The Flow Channel — An Alternative Approach to Measuring Team Effectiveness
How discovering the Flow Channel made me a better Scrum Master
Imagine a team with an almost complete lack of process, that refuses to adopt the Scrum events or any kind of process, but at the same time is proud of their Agility.
They have a Sprint Goal, but see no problem in extending their Sprint by a few days (or a week) to finish the Sprint. Their Daily Scrum lasts between 45 minutes and 3 hours(!), but never anywhere near the 15 minutes they would like it to be. Refinement is either a discussion of their goals, or a fight about process (it seems like every team member has their own idea about what Scrum should look like), but never about PBIs.
Sprint Backlog Items are unreliable at best, often losing any meaning by the end of the sprint, by which time the only way to tell we actually achieved the Sprint Goal is by seeing it working on production and agreeing on the requirements after the fact.
Sounds weird? Well, it happened to me a few years back. I spent months trying to reach these guys, trying to show them how to improve their way of work, but to no avail. I would organise workshops and they would be really enthusiastic about all the things I showed them. Only to go back to their trusted world of total chaos. It drove me to despair.
Eventually, I stopped trying and — pulling my hair out — I decided to sit back and just observe, trying to understand what was going on.
Gradually, I realised these guys, for all their chaos, where pretty much reliably achieving their Sprint Goals. And not just in a delivery sense of the word, but really making serious progress towards reaching their Product Goal.
In fact, they would eventually go on to win a company award for delivering the project on time. It was one of those typical corporate projects with unrealistic deadlines that everyone expected to fail. There were even backup plans in place. No small feat.
And also interesting, we were having huge amounts of fun.
I realised they worked extremely well as a team. They had discussions and fights and often failed to agree, but that never got in the way of a great vibe. Language barriers, missing skills, hopeless dependencies — they took everything in stride and always managed to regroup, patch up and deliver.
I realised I had an ideal team in my hands, if a diamond in the rough.
And that is when it hit me. I was trying to force them into a process without properly understanding them. I realised that as a Scrum Master I had become hopelessly dependent on the Scrum framework to be able to help my teams. Without it, I was blind. I simply had no idea what to do.
Ouch.
The Mental State of Flow
For quite a few years I’d been reading books on Psychology, and — as these things often seem to go — precisely at the time I was struggling with this team, I was reading a book called Flow: The Psychology of Optimal Experience.
In his book, Mihaly discusses what makes us happy as human beings. His conclusion is that true happiness comes from the pursuit of meaningful goals, things that give us a sense of fulfilment. These goals allow us to fully immerse ourselves in our work, leading to heightened focus and concentration. The result is that we become more effective at what we do.
In other words, the happier we are, the more effective we are.
And this doesn’t only apply to individuals. Achieving Flow is easier when working together, for example in a team. So, Flow isn’t limited to individuals — a group of people has Flow too: a cumulative level of Flow.
Mihaly found that for people to achieve flow they need clear goals, immediate feedback, and balance between their challenges and skills. He summarises this beautifully in the concept of the Flow Channel, which you can see in the diagram below.
In the diagram we see how as long as we keep the right balance between our challenges and skills, we stay in the flow channel, enjoying flow and being happy.
But as soon as we stray outside the flow channel we get immediate feedback in the form of anxiety if the challenges are too big for our skills, or boredom if the challenges are too small.
Inspiring goals give us the drive to accept ever-greater challenges and grow our skills to tackle them, and so we gradually progress along the flow channel toward the top right.
Measuring Happiness
So this got me thinking. Perhaps this might be an alternative way of ‘seeing’ a team?
What if we could turn this idea of Flow around, and instead of looking at how to achieve Flow to increase Team Happiness, we could use Happiness to get an idea of how much Flow a team has?
If we accept that the state of Flow correlates with effectiveness (as we also see in the Kanban flow of value), that would suggest that the level of happiness correlates with effectiveness.
Of course, this is not a new idea. The experiments conducted at the Hawthorne Works back in the 1920’s already hinted at this idea. Various books support and build on the idea, such as Rise of Superman: Decoding the Science of Ultimate Human Performance, Deep Work: Rules for Focused Success in a Distracted World and Daniel Pink’s Drive.
We also see that in the Agile community measuring team happiness is a pretty common activity. It seems to be a well-established concept.
However, I’ve always found measuring happiness to be a challenge. I have tried it with various teams, using different questionnaires (including Christiaan Verwijs’ Team Morale), but results were disappointing and unreliable.
A questionnaire is simply not a reliable way to measure happiness. Often, it is a heat-of-the-moment impression. For example, a team member who fills in they are unhappy with the sprint because someone cut them off on the highway on their way to work. Or the optimistic team member, who homes in on that one moment of fun they had by the coffee corner the day before, ignoring everything else.
And then of course there is Goodhart’s Law: teams using the form to indicate their displeasure with management, stakeholders — whatever frustration they have.
I’ve even had teams where the filling in of the form caused their happiness to plummet simply because they got tired of having to fill it in every time — which brings us right back to the Hawthorne effect I mentioned earlier.
So what to do?
Well, research shows (see the books below) that we human beings are very good at recognising emotions in others without actually talking about them. It is what Psychologists call nonlinguistic emotional expressions — we instinctively know how to interpret expressions (and micro-expressions), sounds, posture and all kinds of other clues around us. Check the book Supercommunicators: How to Unlock the Secret Language of Connection, if you want to know more about this.
I completely understand if your reaction is not enthusiastic. I know it sounds pretty weird. Like something from some New Age cult. And when you start trying it out it feels terribly awkward. It feels unscientific.
But the key is to persevere. I started myself by first trying to guess the state of mind of my teams and using the usual less-than-perfect tools (things like Velocity and Kanban flow) to test the correlation with their effectiveness. In the beginning I felt foolish.
It took me almost a year, but eventually I started to get more confident with the approach. I gradually started measuring less and less. I learned to trust my intuition.
The truth is that this skill is like a muscle. We all have it but for most of us it has become atrophied. And just like an atrophied muscle, it takes lots of practice to get it back to life.
The Flow Channel — A new way of measuring team effectiveness
For me the results have been transformative. Before I discovered Mihaly’s Flow, I could gather information about a team’s process and come up with all kinds of ideas for how to help them. But I never knew how they would take it. Sometimes teams would be enthusiastic and go for it. But more often than not, I would lose them and struggle to get them back. it would take ages for me to build the necessary trust to recover from these kinds of ‘mistakes’.
Now, I can get a feeling for a team by joining their Daily Scrum a couple of times, or just spending a few hours with them. I’ll do little experiments, like asking a stupid question to see how they react. Or telling a silly joke.
I will use their activities to determine their different kinds of flow. So for example, the Daily Scrum usually tells me much about how they communicate and their skills with managing their work. The review tells me about their flow within the organisation. The retro offers a glimpse into how they experience learning and the ownership of their Scrum.
Through all of this, I’m constantly updating the team’s Flow Channel in my mind. Anxiety means that their challenges are too big and boredom or even cockiness that they are too small. My job is to balance skills and challenges.
The best part is that I don’t need the process anymore to understand my teams. It has given me a huge boost of confidence in my work. It is the difference between having leading metrics — which happiness is — rather than lagging metrics — which most of our Agile metrics are.
Conclusion
Agile is still so young, there is so much we still need to learn and discover. But instead we spend so much time trying to make sense of a complex world using our old tools, vestiges of an archaic way of work. What we really need is new tools.
I hope to have inspired you with this article to accept that our duty as Agilists is to keep pushing the envelope. Thinking out of the box to find new tools, new tools which truly work in dealing with complexity.
And yes, it is awkward. But we as Agilists should know that change and learning new things is always awkward. Intuiting happiness, a skill we have evolved over millions of years, pretty much feels like a lost skill, something that is mostly unconscious, something most of us are unaware of. It is only through an open mind, creative thinking and a bit of stubborness that we can discover how powerful it can be.
To me that is what the true Agile Mindset is all about.
Thank you for the article. I had a similar experience when I tried to change the team working model to be more Scrum oriented and I failed. Now I use Scrum as a reference, but the team will decide how they want to perform and it was a case of success. Using only the basic principles, but for the rest the team self-organizes intro producing value. This is the most important goal.
Great article, it made me think a lot. Thank you, Erik!