Flow in Agile
Mihaily Csikszentmihalyi, Keith Sawyer and Steven Kotler identified 17 triggers to help create flow.
I will map how the agile practices HELP foster flow. Since implementation of agile has many flavors, I will share the agile values as flow triggers, and the common practices that allow teams to get to group flow.
Individuals and Interactions over processes and tools. Keith Sawyer’s work shows that group flow happens when the group has Constant Communication. An agile trainer I knew, would introduce the different types of Agile (LeSS, SAFe, Scrum, Kanban, eXtreme Programming), and always throw in Common Sense. It took the room a few moments to realize, Common Sense wasn’t a consultant led set of instructions, but actual COMMON SENSE! It always produced chuckles in the room. Daily Huddles are common, but if they aren’t creating a sense of familiarity, immediate feedback, close listening, and keeping the team completely concentrated on the iteration’s goal, then it needs to be refined. Likewise, teams can coordinate to help each other protect 90 minute - 2.5 hours of focused uninterrupted work for complete concentration on deeply creative work to be done. They can do it in the planning sessions, when they discuss how they will complete the work they committed to, they can also adjust in the dailies, if the team finds they have not been able to focus because of other meetings getting scheduled.
Working Software over comprehensive documentation. As stated earlier, Mihaily Csik identified Clear Goals as a flow trigger. No one ever has a clear goal about documentation, but you can have a very clear goal about if something works or not (often, this is called acceptance criteria, a set of clear, binary goals that can clearly be evaluated as being met or not). Also, agile focuses on iterative learning, so instead of a behemoth piece of functionality, smaller increments are delivered, so as to be given Immediate Feedback, another one of Csik’s flow triggers. The working software also equalizes the risk the teams face. Whereas before, if there was a failure in software, product leaders could point to their massive 300 page requirements document (no shame, I too, authored one of those back in the day) and show how THEY had clearly stated what “should” be done. Now, the team accepts work from a product leader (or, product trio, or four in the box) only when they are clear on the work, and that they can complete the work in the given time box. The product leader has that delivery at stake, and is therefore accessible to the team, as well as helps the make decisions (often by empowering them to make their own decisions), eliminate obstacles, and make sure team members get stakeholder feedback - all of this bringing in the flow trigger of Shared Risk, and you know what the flip side of shared risk is? Shared CELEBRATION!!! When your team starts getting into flow, and delivers great work that receives positive feedback more often than not, the celebration is an irreplaceable feeling. Victory is infectious and feels so good!
Customer Collaboration over contract negotiation. Group flow gets triggered by blending egos. Working with the customers rather than battling it out creates more creative solutions. By bringing in customers to give feedback to the latest working deliveries the team has made (if you’re thinking I’m focused on engineering and tech teams when I talk about working deliveries, think again, Sales teams can re-work their scripts and get feedback from customers, marketing can deliver new brand campaigns and get feedback from customers, even HR can deliver new training material, and work with their customers - the company employees - to get feedback on their work), teams can adjust their work, they “get” how the customer uses their work. In fact, seeing a customer interact with product increments creates deep embodiment, because that is the individuals WORK that is getting evaluated, and it also provides a rich environment, because feedback is never the same, there are always new details, new information gathered.
Responding to Change over following a plan. When your teams respond to change, rather than ignore it, your teams regain a sense of control in a world that is uncontrollable really. Using the daily huddles allows the team to identify change early, and adjust. One of the most common changes happens when work that was “supposed to be easy” turns out to be much more complex than anyone guessed. In the dailies, the work can be renegotiated so that the team keeps their challenge/skill ratio in that sweet spot of just challenging enough that its interesting, but not overwhelming. Also, collaborating to respond to change triggers the Yes, and trigger. “Yes, and” is known by improv comedians and freestylers worldwide - if you wan the art to go somewhere, just go with the last thing that was said, but if you battle it, the magic can’t flourish.
One common, critical agile practice I have not mentioned above (on purpose), is the Agile Retrospective. Commonly held at the end of a sprint, this gem is a meta moment for the team - it is a chance for the team to look back at the time box (sprint, iteration, whatever you want to call the time period from planning to delivery), and adjust how they will get better. They can ask themselves how much flow they are experiencing, how many distractions are keeping them from focusing, if priorities change, or if the work that they thought was clear turned out to be confusing midway through the time box. They can use this time to discuss their whole process, and you as a leader can help remind them of some of the individual hacks to flow, and make sure the teams are getting those in. At the beginning of the pandemic, it was not uncommon to have 10 hours of meetings back to back, with no break. I remember I had to embarrassingly apologize because I was stepping away form a meeting for a bathroom break - how crazy is that?!? If that is still your experience, I recommend leveraging a planning session to map the work you are committed to delivering against the next two weeks. Protect your periods of deep work. Sometimes, I do schedule time blocks to get the work done, but only when my calendar gets filled with other people’s work (aka, meetings).
Flow in Meetings
Create flow in your meetings by:
Ensuring everyone knows the purpose of the meeting
You have the right people in the room
The meeting is solving a challenge that cannot be done alone or through email
Ground rules set a “yes, and” culture - welcome all ideas, then vote for top ideas
Everyone respects each other in the room, and individuals participate equally. You may need to use breakout rooms to ensure equal participation, but they are worth it!
Consequences are clear for the action steps, and individuals own getting them done.
Flow for Leaders
If you are in a leadership position, you probably have dialed in your own flow cycle over the years. One thing to realize is that most people have not, possibly even the people you lead. We live in a world where knowledge workers face 50+ distractions a day, and can focus on their work for 11 minute stretches at a time.
As a leader, you will need to learn how to trigger flow in others. Here’s a Do and Don’t list to help you get there
DON’T assume everyone already knows the goal
DO make goals clear
DON’T give a massive problem to an individual and tell them to figure it out
DO help your team break down their work to meet their skill level
DON’T book meetings at every random time of the day
DO protect time for your teams to create one or two 90 minute blocks of focus time each day
DON’T have lunch at your desk!
DO take breaks every 90 minutes, encourage others you lead to take breaks as well
DON’T play favorites
DO encourage equal participation
DON’T tear down ideas
DO encourage ideas and share what would make them even better
DON’T just say work has to get done
DO share why you prioritized the work for now