For many people Agile means attending more meetings and adding more detail to Jira tickets. People get worn out by that.
Richard facilitated a session at Agile2024 on “Addressing the Psychological Costs of Agile.” In this episode, he dives into the fishbowl facilitation method used in the session as well as some of the key takeaways from the conversation.
Resources
Liberating Structures: User Experience Fishbowl
They’re All Customers
Your Turn
Have you ever used liberating structures? If so, what’s your favorite one? We’d love to hear from you! Shoot us a quick email at mailbag@humanizingwork.com.
Subscribe, Like, Share
If you haven’t subscribed to the show yet on YouTube or your favorite podcast app, why not do that now? We’re planning to continue shipping an episode every week, and we’d love to have you on the journey with us. Click to subscribe now.
And please rate and review the HW Show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share. Your help spreading the word is super meaningful to us!
Episode transcription
Richard Lawrence
Hey, welcome to the Humanizing Work Show!
I’m just back from the Agile2024 Conference in Dallas, Texas, where I had a great few days catching up with old friends, meeting new people, helping out with the Agile Advice booth, and leading a session on the Audacious Salon track.
In case you’re not familiar with it…The Audacious Salon track is different from a typical conference track where people submit session proposals around a topic. For Audacious Salon, the track chairs select a few meaty topics and then invite experienced presenters and facilitators to lead multiple sessions on each of those topics using different formats to explore the topic from different angles.
So, was invited to lead a session using a fishbowl format to dig into the ways in which adopting an Agile way of working has a high psychological cost.
In this episode, I’ll share more about the fishbowl format and how you can use it, and I’ll share some of the interesting things that came up on the topic of the psychological costs of a big change like an organization adopting Agile.
But, before I get into it, a reminder that this show is a free resource sponsored by the Humanizing Work company, where we help organizations get better at leadership, product management, and collaboration. Visit the contact page on humanizingwork.com and schedule a conversation with us if your organization wants to see stronger results in any of those areas.
So, back to today’s topic, let’s talk about the fishbowl format first. The format I used was based on the User Experience Fishbowl facilitation method from Liberating Structures. I’ll link to it in the show notes so you can read more. Here’s how it works:
The goal with a fishbowl discussion is to collect concrete experiences and reflections around some topic. It’s designed to try to avoid people giving speeches and sharing abstractions.
So, the room is set up with an inner circle of people who are having a conversation on the topic and an outer circle of people who are observing the conversation. I actually set up my session as an arc of chairs for the so-called inner circle facing a few loose half circles of chairs for the outer circle. It just worked better in the room I was in for everyone to hear each other and to see the topic and the rules of the approach on the projector screen.
The inner circle, however you organize it, has 4 chairs, but only 3 participants at any given time. If someone from the outer circle sits in the empty chair, they’re joining the conversation, and then somebody else gets up from the inner circle and moves to the outer circle. If someone from the inner circle steps out, someone else steps in. So the group is self-organizing, to always have three people in the conversation. Not two, not four.
After some time of the inner circle conversation, the leader facilitates a discussion to collect the outer circle’s reflections and insights. And that can be done by having small group discussions and reporting out, or it can be done as one larger conversation. It depends on how many people you have.
Now, a fishbowl can be tricky to facilitate. In many facilitation formats, the facilitator is involved throughout the discussion, asking questions and giving instructions. In a fishbowl discussion, the facilitator sets it up, but then only intervenes lightly unless things are going off the rails. Because you’re trying to keep a lively 3-person conversation going, I found, when I do that, I’m very aware that if I say anything, the conversation could come to a halt and lose its momentum.
So, there are two main places where a facilitator makes a fishbowl work: in the framing and instructions at the top, and then via body language and a word here or there during the discussion (for example, to invite someone to step into the inner circle or to remind participants to talk to each other, not to the outer circle).
So, for my Agile2024 session, I introduced the topic at a high level. Then, I explained the fishbowl format and the different roles participants could take throughout the session. I emphasized that the goal was to bring out stories and reflection from real experience, not speeches or theories. Because, to be honest, you get a lot of those at a conference. They’re sort of set up for it. We wanted this session to be different.
Then I offered a few questions we might explore about the topic and gave participants 2 minutes for silent reflection to think about what experiences they’d had related to those questions and the topic more broadly. I invited them to take notes so they’d remember things that they could share.
Then, I put up a slide with both the questions and the fishbowl rules and invited a few people to step into the inner circle to start the conversation. So, three people sat down, and we were off and running.
After about 45 minutes of lively discussion, I invited everybody to share their reflections and insights from listening to the conversation, and we wrapped things up.
Before I get into some of the takeaways from this particular fishbowl session, I want to share some thoughts on the fishbowl format:
First thing that comes to mind, I really like how keeping the conversation in the inner circle small makes it awkward to give speeches and that helps keep things focused on personal experience. And I even notice this when I’m facilitating. If somebody who is talking is looking at one or two of the other people in the inner circle, it feels like a conversation; it stays pretty concrete. As soon as they start looking at the rest of the room in the outer circle, the conversation changes and they start sounding more like they’re giving a presentation.
Now, I like that. But that said, if you want to facilitate with a light hand during the conversation, like I prefer to, this format is fragile to people monopolizing the floor. Now, that could be my inexperience with the format, and I’m not totally clear yet on what stops the conversation vs channeling it in a more useful direction, but I’ve facilitated a lot of things over the years, and I found myself wary about intervening and losing momentum while also getting concerned a couple times when somebody got on their metaphorical soapbox.
Framing the conversation and being super-clear about the rules seems to be key. If I’d forgotten something important in the framing, it would have been difficult to bring in later. Again, because it’s one free-flowing conversation, facilitator interventions risk killing the momentum.
I could see using this format in other situations where aggregating personal experience is useful. Maybe debriefing a simulation in a workshop could be an interesting application. I’m not really sure. I’m keeping it in my facilitator toolbox, even if it’s not something I’ll reach for first. If you have used this in other contexts, we’d love to hear about it. Comment on YouTube or LinkedIn and let us know where you’ve used the fishbowl format and how it’s gone for you,
Now, let’s get into the content of this particular fishbowl session. The topic for my session was “The psychological costs of adopting Agile.” I posed 4 questions we could explore as a way to frame the kinds of things we might talk about:
- What are those psychological costs in practice?
- How are these costs distributed unevenly in an organization?
- How are some of the things Agile champions, like us, consider dysfunctions actually doing a job to mitigate the psychological costs or pains for somebody else?
- What are some practical ways people have reduced, mitigated, or eliminated the psychological costs of adopting Agile?
Reflecting back on the conversation, the biggest theme when it came to examples of psychological costs associated with adopting Agile was this: People want to be good at what they do. And they want to be seen as good at what they do. And the way Agile changes roles often takes away things that people got that sense of competence from.
We heard examples of this across the whole range of roles. Managers who used to provide technical leadership in the work who were now supposed to stay hands-off. Developers having to work outside the specialty that they’d built their reputation on. Business stakeholders who used to be able to give confident answers about delivery dates now being told, “You’ll get whatever gets done.”
Another theme was the way different practices mitigate these psychological costs. For example, splitting stories to focus on value is a case of trying to give leaders some of what they need to be competent and to be successful while also balancing developers’ need to commit appropriately and to avoid burnout.
Of course, not everything that mitigates these psychological costs is helpful or productive in the bigger picture. For example, an engineering manager getting into the weeds of the work to recover that sense of technical competence probably isn’t the best thing for the team, even though it may overcome that psychological cost.
It wasn’t exactly about the psychological costs of adopting Agile, but another big theme that emerged was around what a few people called “Agile burnout.” A big part of this seemed to be burnout from processes and tools, and especially in environments where that’s what people experience as the Agile stuff. Of course, this is ironic, given the Agile movement’s early emphasis on valuing individuals and interactions over processes and tools. But I think it captures the state of things in a lot of orgs today. For many people, if you say Agile, they think of attending more meetings and adding more detail to Jira tickets. And people are getting worn out by that.
The biggest and most effective mitigation strategy that came up in the conversation seemed to be just actually paying attention that these psychological costs exist around an org change and that they’re often unevenly distributed between different roles. And then you can take steps to try to find ways to make the change benefit everybody.
This made me think of the concept we talked about way back in episode 77, “They’re All Customers,” where we looked at using customer research tools for things like org changes. The psychological costs we were telling stories about in this conference session were often just the flip side of what I would model as psychological jobs on a customer profile.
So there definitely seemed to be some pain there and some efforts to overcome it, and in addition to commenting on the fishbowl format, I’d love to hear from you on this topic, either on YouTube or LinkedIn. What psychological costs have you seen in practice from adopting Agile, and what techniques seem to have worked for mitigating or overcoming those things?
Thanks for tuning in.
Last updated