More than overdue for part 3. I will always think tools that help you clarify how you work with others are a good idea, but lest you think this entire series is a treatise on Working Agreements… let’s change gears.
The overwhelming feedback I saw on what works in the Mentimeter that I shared in the talk that inspired this series, was human connection. Building teams, camaraderie, experiencing things together. Knowing your biases when you are in a given working mode and pushing past them.
Easy example:
Being remote sometimes makes it easier to “just wait for an answer” instead of getting an answer to unblock the team
-feedback in Hybrid Agility talk at CodeMash 2024
Heck yes. This is a way of working bias that often expresses itself on hybrid teams. Especially when the “wait for an answer” part of this is built into the team given non-overlap working hours for people spread across the globe.
Bias is inherent in any group of people. As Daniel Kahneman explains in Thinking, Fast and Slow mental shortcuts are necessary for people to get things done. The tendency to “wait for an answer” is a bias. Neither inherently good or bad, and you come to understand it by either experiencing it yourself and examining your thinking, or experiencing it as a team, often with a negative consequence of some kind.
If you’re not yet familiar with the fast and slow thinking, fast thinking is intuitive, relying more on experience and gut feelings. Slow thinking involves a more deliberate, analytical approach. This is a different kind of thinking that emerges by slowing things down and examining your thinking, looking at the data, and taking different perspectives. This kind of reflective thinking is highly valuable in agile environments which is why agilists reserve time for it in order to learn. Slow thinking can be assisted by personal reflection in the form of mind mapping, reflective practice, and deliberate practice. It can also take the form of team learning in root cause analysis or a retrospective.
Retrospectives are, in my view, one of the most powerful agile practices, and they are frequently underused and undervalued. It may be because of the name. They are really collective learning sessions that help people use slow thinking together. Through reflection and revealing our thinking to each other we build bonds. This happens naturally in getting to know other people. It also happens when we decide it’s an important part of how we work.
We are different people, and so we may have different perspectives on what is happening when we are doing the work. Some things might seem sub-optimal to one person, and highly effective to another. We might never know this if we didn’t talk about it. Absent that information, many people naturally begin to make up stories about what is happening instead. What is really happening? What do we want to happen? Do we all agree? If not, how can all of our different perspectives be true? Retrospectives can help us deconstruct the story and look deeper.
Yet, most agile team members know retrospectives through the all-too-familiar lens of ‘what worked or what did not.’ It’s how most of developers refer to the retro when asked and it is can be so much more, not all of which are even focused on the past. They can be used for visioning the future… ahem… creating working agreements… helping teams work together better, changing the way of working, and improving the work.
This shared learning process is transformative, allowing teams to assess their performance in a non-threatening environment and decide to try something different. The difference between retrospectives and adhoc continual improvement is that the team is learning together. Learning together is a force magnifier. It helps us understand each other and how we think. It creates the condition for teaming and social connection. It helps us understand motivations and differing perspectives, and probably most importantly, it helps us collectively look at the work we have done in performance mode, and strategize how to do that better, in a safe, non-performance learning mode.
In a sense, retrospectives are a place to amplify the signal when something is not going well, and as with many agile practices, they are not really as important when things are going well – you practice this by doing it when they are, and you really dig in when there is a problem.
So what does that have to do with hybrid agile teams? There are all kinds of biases that we cannot see and may be unaware of; some of the most obvious have to do with very visible things that we can take for granted: everyone is coming to this meeting in the same frame of mind for example.
Are they? If it’s morning for me and night for you as members of an agile team that has multiple locations around the world… there’s probably some other things that factor in to how you show up to a meeting, or how you want to collaborate, or how we choose to work together on the work. At the time we are meeting, it might be just before lunch for me, and just after dinner for you. If the topic at hand is a particularly difficult one, that could impact our collaboration.
Another easy example, “Working in this way will save us time.” I’ve heard this again and again when people justify “improvements” that turn out to be counter productive. In trying to save time, we take more time. In taking more time, we need to make additional adjustments trying to address it:
- “Let’s just spend more time hands on keyboard.”
- “The standup is a waste of time just post your status to the slack channel.”
- “We don’t have time to improve.”
- “We can’t prioritize. All of this work is very important.”
What are the biases in statements like these? Are they serving you?
Some biases you’ll want to keep ex. bias for action. Some you might want to challenge ex. we have to work on this at the same time. Using an example from part 2, if our different timezones seem like they are getting in the way, maybe we ask, “How might we use the timezone difference as an advantage?”
So, my suggestion is simple yet potentially transformative. Examine your biases. When you catch yourself judging something, what data factored into that? As a team, ideally with an experienced facilitator, pause to think about how bias might be either built into, or assumed in, the work you do, how you do that work and how you track and organize the work.
Think about what you pay attention to, and what you talk about. Think about what you don’t pay attention to and don’t talk about. As an individual, as a team, or as a leader of a team attention is a powerful tool. Use it to examine some your thinking. It could lead to rethinking, smashing through imaginary boundaries, and helping to achieve awesome things.
Here are my suggestions for you:
- Spend some time thinking about the things you make assumptions about at work: meetings, collaboration, roles, work, etc. What leads to you assume those things? What do you think people on your team assume and why?
- Often key innovations come from rethinking something we assumed was unmovable/unchangeable because someone without the same bias as you discovered it WAS unmovable/unchangable by trying something different. Where could you experiment with this?
- When something seems less than optimal, and you ask about it, what kinds of answers do you get? Is it explanation? Is it defensiveness? What could someone be assuming about you or the topic that could be at play in the conversation?
Let me know how it goes. Perhaps you have your own list of questions or experiments that you run, in which case, I’d love to learn from you.
