Agile, Retrospectives and Team Health : Expert Insights

Conversations around agile can often be centered on the Scrum framework, with its scheduled meetings and defined roles. However, as agile philosophy continues to mature, is this spotlight shifting? In this interview, Full-Stack Agile Coach Jon Fazzaro addresses that question and more.

Things with a bang as Jon challenges relying solely on Scrum as a launchpad for agility. Instead, he advocates for a more organically agile approach.

As the discussion unfolds, the retrospective takes center stage, and the role of the coach is examined.

Last of all, insights into agile team health are shared along with invaluable advice when it comes to supporting your team.

Let’s dive in!

I’ve read your piece on Medium The Retrospective is the Heartbeat of the Project. Do you still think that’s the case or would you say that there’s something that’s more important that should be considered now?

Since writing that piece, I’ve definitely moved past thinking Scrum is the best way to start being agile if you’re not already.

I’m going to steal a metaphor that the head of our company, Joshua Kerievsky,  shared a while ago in a talk that he did.

When you’re learning to ride a bike, you have training wheels. At least, that’s the way most kids do it; they have little training wheels bolted onto the side of their bike. What they learn to do first is to pedal. So, when you take the training wheels off, the first thing they do is fall down. They don’t realize that they have to pedal forward. They haven’t learned to balance.

There’s an alternative way of teaching kids to ride a bike. It’s called a balance bike. It’s very simple. It doesn’t even have pedals. It’s bike-shaped, with two wheels and a seat. And you just tell them to walk; walk their way along and see if they can scoot and maintain their balance.

That’s the better way to teach a kid to ride a bike. Balancing is the thing that’s hard, not pedaling.

In the same way, Scrum is the most common way for teams to say ‘OK, we need to get agile, let’s go ahead and adopt Scrum’. Then they go ahead and bolt their Scrum training wheels on. They say ‘these are the meetings, these are the roles, and this is what we do’.

Unfortunately, in practice, Scrum doesn’t do enough.

Don’t get me wrong. On paper the guide is very good. It’s got a lot of very good ideas. But Scrum doesn’t tend to do enough to teach a team what it really needs to be agile.

With your position on Scrum and its relationship to agile having evolved, what about the retrospective?

I still believe it’s important to stop working and talk about how you’re doing the work. I think that’s the most important thing. I like the idea of having more frequent retrospectives. To turn the heartbeat up.

The team doesn’t have to do an intense, two-hour retrospective every day. Instead, maybe if you took a half an hour each day at a certain point that remains, a heartbeat. You might discover things sooner that are important. Rather than waiting two weeks to fix ‘the thing’ and amassing a backlog of ‘other things’ to cover, the team can address it almost immediately.

Frankly, that’s more agile. Rather than batching it up and waiting.

What could that regular, possibly faster heartbeat mean to the management team of an organization?

Ostensibly that they care about the fact that the team is healthy, and performs at a predictable rate. As the people minding the business that teams serves, they want to be able to rely on that team to produce what they need in order to meet their business goals.

If a team is not regularly meeting and tuning itself  in, that team might become unpredictable. They might have had a stellar week because everybody put in extra hours, but they are burnt out. Then they just create bugs and nonsense for the three weeks following.

So that’s what I would care about in a management position. I think that there is a really great deal of value in knowing that.

What indicators, not necessarily data, could a Scrum Master be looking for given not all of them have a development background?

Well, in the retrospective, a Scrum Master is fundamentally their coach.

If we apply a sports metaphor, usually a coach is somebody who is an expert in the game. Maybe a former player. To be useful, they have to take the stance that they can’t help the players by playing themselves.

The person running the retrospective has to step outside the content of the conversation. They have to look more at the contour of the conversation.

So, it could actually be of benefit if they don’t understand certain things being discussed because those things could be a distraction. It could take their focus away from watching how the team is interacting. Let’s say somebody keeps getting talked over. That’s where the coach could step in. They can help to try and adjust the conversation.

While the content of the conversation belongs to the people having it, sometimes the mechanics of it go wrong. You need somebody there who’s only watching how it’s happening. They can be nudged into ‘playing’ better with each other.

They are helping to make sure that ‘play’ is optimized?

Yes.

If they want to take things up a notch, what could the coach be doing?

Well, the phrase that comes to mind is ‘holding space’ from Open Space Technology.

Holding Space is its own job. That’s what a facilitator of retrospective would be doing whether they are a coach or a Scrum Master, whatever their title. That role of facilitating the conversation. You’re not in the content, but you’re creating the container, and watching the contour of the conversation.

That entails communicating how you’re going to have the conversation. You’ve arranged for the prompts for that conversation. You’ve set the boundaries. It takes a lot of design work.

In my experience, when a retrospective doesn’t go well, usually the thing that’s lacking is that the person facilitating it hasn’t taken the time to design it. They are just kind of winging it.

That’s not useful.

What’s useful is for them to establish a time box, say 10 minutes. When that time box is up that they’re not fluffy about it, they’re firm. ‘OK, we’re done talking about that, it’s time to time to make a decision and move on’.

So those parameters are really quite important to make it an effective space.  What have you observed go wrong that a simple fix could have addressed?

In terms of retrospectives, the common mistake is to say, ‘let’s have a wide-open conversation’. Then the group goes on to talk about whatever is on their mind. While that’s an important thing to do in some spaces, you really want to get punctuated value out of the time that’s put aside for a retrospective.

Remember, we’re not working on the work. We’re working on the team. We’re working on how we work.

The thing that often gets skipped, on the way to discussing how we felt about what happened, is establishing what actually happened. Making sure that everybody in the room has a similar mental model of what we’re talking about.

So, an alignment. A calibration of ‘do we agree on the facts?’

Often, for me, a handy device to help do this is to take a few minutes and have the team establish a timeline of what happened. Draw a horizontal line on a board and start putting down notes on it. ‘Early in the sprint this happened, then there was this’.

This works against any recency bias. They’re not just going to think about the things that have happened in the last day or two, or hour or two. This is important especially if it’s a two-week iteration, or one month or longer. There are a lot of things you won’t remember.

Giving them time to actively remember is really helpful.

There might be parts of the team that didn’t feel the same or didn’t remember things as strongly. They might have heard about something, but they weren’t involved. So it paints a picture for them that’s a little more holistic and shared.

From that point, once the team agrees on what happened, then they can talk about what that means and how they feel about it and what could be better.

Amnesia can be addressed first.

Or just completely different points of view. Completely different mental models of what happened can be addressed before the retrospective starts.

So, imagine the alternative. Going right into talking about, ‘was that good or was that bad?’ You have people with their own versions of what happened in their head. Those stories are all completely different. It means the words that they use to describe things are going to be completely inappropriate from the other person’s point of view. There’s going to be no connection. No insight can come from that.

Now to tap even further into your mastery of the metaphor. If the retrospective is the heartbeat, what’s the team?

It’s a system. A body of organs working together. Doing different jobs. It’s trying to keep going, to grow, to learn. It’s trying to be healthy.

That does segue, really nicely, into the topic of team health. Have you ever encountered a team that is dysfunctional but effective? There are high functioning people who have real issues.

Sure, they are getting through their day. That’s the phrase though, ‘getting through it’.  If you get through something, you know there’s probably something that’s difficult that healthier people don’t find difficult. There are missed opportunities.

This takes us back to predictability. I would think that one of the most devastating things about having a serious health condition is how unpredictable that would make my life. I couldn’t, really reliably, make any plans because I don’t know if I’m going to suddenly fall over. I might need an ambulance and go to the hospital. There goes my week.

I think that’s the thing about health and the health metaphor. You are putting in this extra effort to improve things so that the world becomes easier.

In my own, personal experience, I’m kind of terrible when it comes to exercising and maintaining a routine. But there have been periods in my life where I’ve been good at it for a few months. I would do something kind of minimal. Say, 10 push ups every day. And I’ve been good at that for a long stretch.

When I’ve been good at that, my keenest observation about how I feel is that not that I feel bigger or stronger. But I feel like the world got easier. Difficulty is turned down.

That smoothness. That ease of movement when you’re healthy. That’s why I think that’s what you’re going for with a team when you tune it up properly. The effect that has on the people that that team is doing work for is that team is predictable, like a clock, it’s reliable, you know?

There’s an idea from Tim Ferriss’ The 4-Hour Body of minimum effective dose. You don’t have to be in Olympic shape, it’s the minimum to have a positive effect. What’s the minimum that we can do to have an effect, a positive effect on the team. Which is enough in many cases.

What could someone facilitating a retrospective look for to gauge the health of their team?  

Well, they should definitely see decisions being made. The scenery changes on the healthy team. They are tweaking. They are adjusting. They are experimenting freely.

Responsibility doesn’t lie at an individual level. It lies with everybody. There’s sort of this blameless atmosphere of, ‘hey, that didn’t go so well’. They might identify that somebody’. did something and it caused a problem, but you wouldn’t say ‘when you did that, that really screwed everything up, and what are you going to do to fix that? It’s more, ‘what can we do better to react to that?’ You know the responsibility belongs to the whole team, even when it’s one person’s actions that might have caused something to go wrong.

In general, there’s a notion of blamelessness.

They handle conflict well.

A go-to symptom of a good team is that they are not quiet, they complain. Because they have a bedrock safe atmosphere in which they feel able to bring things up to bother them.

With 30 seconds to go and no forewarning, what’s your ultimate pearl of wisdom  for any person embarking an agile endeavor?

Stop to retrospect before you need to.

A lot of teams will only meet about the thing once it becomes a problem, and well, it’s easy to skip the retrospective when it feels like everything is fine. If you have done that, you haven’t inspected closely and discovered the thing that might cause us a problem. Weeks from now or days from now.

A huge thank you is extended to Jon Fazzaro for participating in this interview.

Jon is a Full-Stack Agile Coach, and has been in software development for over twenty years. He is a hands-on advocate for modern agile practices like ensemble programming, test-driven development, and daily collaboration with stakeholders. He is also a strong proponent of Lean Product Management and Systems Thinking.

Jon has been a regular speaker at software conferences since 2015. You can head to “Oh! The Humanity.”  a close-up of his current professional thinking.