(upbeat music) - Okay, so I can probably start by introducing myself. My name's Nicola.
Thanks so much for the intro, Gen.
As she was saying before, what I do day to day is I'm a product design consultant.
I'm working at Pivotal Labs, and what that means is that every couple of months I am working with essentially a completely new group of people, so they're my new clients.
This means that I've worked with lots of different sets of people, different sets of teams that have different ways of working together, so I've had a lot of experience with different kinds of teams and how they work. I was also part of the original team who created Postfacto.
Postfacto is this tool that is a way to run remote retros.
That was the original problem that we tried to solve with this.
I just looked at the screen.
It's actually eventually become something that's become quite integral to up to around 2000 teams around the world who are using this to run their retros.
So, I'm pretty passionate about retros and yeah, I was pretty excited to hear somebody was running a retro before.
Okay, so what I'm here to talk to you about today is retros, otherwise known as retrospectives, sometimes agile retrospectives, sprint retrospectives, post mortems.
People have different names for them.
But essentially it's the meeting where your team is coming together to talk about how things are going. So I have a question for you.
Who here does retros with their team? Sweet! Heaps.
Who has been in a retro that felt like it was maybe a bit of a waste of time? A lot of hands, yeah.
And who here works in an agile team but doesn't do retros? Okay, sweet, not too many.
That's good! So what I'm gonna share with you today is why great retros make great teams.
And I'm gonna talk you through the research that I and my team did into retros for Postfacto. And I'm also gonna talk about the common pitfalls that befall teams around retros and how to avoid them. So, at the end of this talk you are going to have learned how to run simple effective retros that help your team to communicate better and run more smoothly.
I have a story.
I remember my first retro.
It was around about two years ago.
So it was when I first started at Pivotal Labs. And this in itself, the fact that this was my first retro, is a little bit surprising because this was not my first time working in the tech industry, not even my first time working in an agile team. But it was within the first week of starting, and I was sitting in on a scoping.
A scoping in the world of consulting is where a set of potential clients come in and you work together with them to work out whether there's something that you can work on together. So it's a pretty, like, structured full day workshop. And in this particular workshop it was a pretty tough one. What they say is that facilitating a meeting is a little bit like flying a passenger plane. You need to get a group of people from point A to point B.
It's not enough to take off from the ground, fly around for a bit, and then land back where you started.
And the other thing they say is there will always be turbulence.
There just is always gonna be turbulence on a plane. So, in this particular meeting, it was kind of like a hail storm outside.
There were clients who were fighting amongst themselves. There was one person in the room who was clearly there to try to derail the entire thing. He just didn't want this project to happen at all but he wasn't able to say it.
There was one person who kept leaving to take phone calls at absolutely the worst possible moments.
It was a really tough day.
And there were three people from my team in the room and about eight clients.
So we finished up at five.
The clients filed out, the elevator dinged, the room was quiet, we all sort of looked at each other and drew a deep sigh, and the one girl who was facilitating the room said, "Wow, time for a retro?" So we each took a pen and we wrote on the whiteboard in the room about what went well that day, what we were left wondering, and what didn't go so well.
And then for the next hour we sat together and we talked about everything that we'd written on the board.
So we talked about how we felt.
We talked about what went wrong.
We talked about if we could do things differently in the future to mitigate the same thing happening again. And we also talked about how the room could have been facilitated differently to have a better result.
So that was the part that felt really cool to me because the facilitator in the room approached the conversation that way too.
We all looked at it as something that we could improve upon together.
She didn't feel hurt or criticised by us talking about this day as something that we could all work on to improve.
We communicated with each other openly without judgement at work and it really felt ground-breaking.
Yeah, so like talking about your feelings at work kind of weird I guess.
But, I don't know about you but I'd never really worked in a job where people actually communicated openly with each other.
So my expectation that day was that we would probably dust ourselves off, we would probably pretend to each other that we had all handled that totally fine, maybe we would deal with that on our own.
I think perhaps if it had been me facilitating, maybe I'd feel a bit nervous, a bit worried that potentially the failure of that day would become limped upon my shoulders.
It's not very nice.
But that's really the only kind of workplace behaviour that I'd actually seen modelled before.
But it wasn't like that.
And what I've found since then is that it's the teams that don't feel like that, that don't act like that, that the teams that actually do openly communicate with each other, those are the great teams.
And those are the teams that create really great products and really great outcomes. So that's why I'm so passionate about retros. Because at first glance it's just a meeting. You know, nothing ground-breaking.
But actually it's a really powerful tool that helps to create a team that works really well together because they communicate really well.
So let's talk a little bit about what a retro looks like. There're a lot of different ways to do retros and today I'm just gonna talk about one of those. Part of this is because I'm a product designer, I believe in the communicative design, I believe in doing your research and then choosing the one way that you think is the best and then recommending that.
So that's what we've done with Postfacto, and that's what I'm gonna do today.
So, this is what a retro looks like with Postfacto. It can just as easily work with a whiteboard and pens, with a bunch of post-it notes and a wall.
You don't need to go hi-tech.
All you need is a way to have three columns and a way for everybody in the team to add things into them.
So these three columns, essentially it's happy, wondering and sad, aka like you can say "I'm glad that", "I'm wondering about", "It's not so great that". Happy, wondering, sad.
And the basic structure is this.
So you're gonna take an hour with your team, the people in your immediate team are gonna join, and you're being mindful and asking yourselves how is this week.
Ideally you're doing this every week.
So everyone's gonna put items in the three columns, whether that means your whiteboard, whether that means Postfacto, whether that means post-its.
You're gonna take five minutes or less per item and talk through them.
And for each item you're gonna ask: Is this something that we can try differently next week to make next week better than this week? So what is the purpose of this? The purpose is communicating with your team on two questions.
Number one, how are things going for us? And number two, what can we change to make next week better? And that's why retros will continue this improvement for teams.
This process of being mindful and constantly asking yourself "can we improve" even if it's just a little bit.
So let's talk about the research.
I ran research into retros as part of the process of creating Postfacto, and over the period of over a year, concurrent to the building of Postfacto, we're building in an agile way, I ran user interviews with a whole bunch of people about their experiences with retros.
So, we talked to people who are really good facilitators, who have really amazing single retros and amazing processes of retros, who are just running this continuously in a really productive way.
We also spoke to people who have had really bad experiences with retros.
I also sat in on so many retros.
We're dogfooding our own product from actually week one, we ran our own retro with Postfacto, which is pretty cook, our engineering team is amazing. Plus just speaking to so many people publicly about retros and hearing different people's stories. So, I've heard a lot of stories about retros. I've heard about good ones, I've heard about bad ones, I've heard about pointless ones, I've heard about actively harmful ones.
Our goal with Postfacto was to design a tool that would help people to have these good helpful retros consistently and build that into a long term practise.
I'm gonna talk you through four of the biggest pitfalls that we had and how you can avoid them.
We'll turn them round if they're affecting you. So the first one is the painful, the awful, the explosive retro, the emotional ones, the finger-pointing ones, the ones where the team walks out of the room feeling worse than they felt when they walked in, the ones where people get hurt, the ones where somebody walks out feeling blamed or shamed.
Those retros are bad.
What really helps, in my experience, is regularity. So, it can feel like a bit of a contradiction like our retros really suck, we really hate them, let's do it more.
But that's what we found.
I've spoken to people who, you know, I've said, "Do you guys do retros?" And they're like, "Yeah, we've had a couple "but we usually don't really feel like we need it." That's where I would say, "If you wait "until you feel like you need it, "then it's already too late." If there're people in the room who feel like we need retro, then you've got problems. Over-communicating is way better than under-communicating. We like to say that retro is like scheduled maintenance for your team. Don't skip it.
Have it every week, whether or not you feel like you need it.
What also helps with these kind of painful, awful retros is to set expectations at the start.
So frame the experience.
What you can use is something called the prime directive. We know that everyone did the best job they could, given the situation and the resources they had available at the time.
So failures are an opportunity to improve so we all get better together.
What you're doing is setting the scene as a positive place of learning and a place where everybody's voice is equal. It's also important to talk about everything on the board. Don't skip over items.
And we also recommend don't vote on which items to talk about and skipping some other ones that didn't get votes.
I think if it's important enough to somebody to put on the board, then it's important enough to talk about.
And I have an example.
We always have snacks in our retros at Pivotal, and often the snack is cheese.
Personally I love cheese.
In a recent retro that I was in, somebody had written cheese up on the board and I was facilitating this retro.
And so I think as a facilitator it's pretty easy to look at that, you know, cheese item and be like "Well, obviously, that's just a nothing item," like they're just going, "Yeah, sweet, we've got cheese." But I didn't skip over it.
I said, "Okay, cheese, who wrote that one?" And I was surprised because somebody put the hand up and said, "Yeah, it was me "and I just wanted to bring this up.
"We always have cheese.
"I can't eat cheese.
"Nobody has ever, like, even noticed this about me. "This has never come up." And I could see that this person, it was kind of bothering them.
They were sort of starting to feel a little bit like they weren't being heard, like they weren't being included in the team. It sounds like a little thing but that's actually something you kind of want to tackle. You don't want somebody in your team feeling like that. So that's why I think it's important to talk about everything and just open up the room to who wrote this one.
Pitfall number two.
People are not really sharing the truth.
I've been in retros and I think probably a lot of us have that you can say that there are people who maybe they have things to say but they are not saying them.
Like at some point in the past or in this today they have decided "No, I'm zipping my mouth, I'm not gonna share." That really sucks.
Like why did they decide that? And that's not a thing about them, that's probably a thing about the structure or the context. Because the point of retro is to look at what's going well and what's really not going well.
And if people don't feel safe to share, then that's something that you wanna tackle as well. So how can you make it a safe space to share? A really good way is by being mindful of who is in the room.
We recommend only inviting the immediate team, the people that you're working with directly day to day. So somebody's presence might compromise the feeling that it's safe to talk about things that aren't going well, I'm thinking direct managers, stakeholders, anybody who is kind of judging the performance of the team. Those people should probably sit this one out. The other thing that you can do to help this is to be vulnerable.
And if you are the person in the room who's got more experience with retros, maybe that's you.
So, I'm a consultant, as I said before, so I'm often working with brand-new groups of people who are often new to retros, and what I will do is I will take the first step to be that person to be vulnerable in the room and set the scene that that's an okay thing to do.
So for example, just last week I had my first retro with a brand-new team.
They're awesome, I love them.
But as one of the first items I brought up my own set of sad items.
So we'd been in a full day meeting and I noticed a whole bunch of people left at midday and I was thinking in my head I was like, this is kind of almost like the elephant in the room, why did all these people leave, was that a walkout, is something wrong? So I wrote that, I wrote that up on the board in the sad column and I asked that question. I think just being the first one to be open and bring up the thing that's kind of maybe a little bit uncomfortable to talk about, that's often enough to set the scene and model the kind of behaviour.
And I saw as soon as I said that and admitted that I was a little bit worried about it, showed them that we could talk about this sort of stuff together, I saw the vibe in the room change.
And it really works.
So pitfall number three, the room being dominated by one or two voices. This is a common thing in lots of different meetings and it's probably just a matter of different kinds of personalities and people with louder voices, but the people who would talk way more than anyone else. So what really helps is having a strong facilitator. That's one of the things that can lose that from retros, I think we even see ourselves falling into this trap of not saying this person is the facilitator and sort of, you know, get yourself into the facilitator mindset and do that job. So, if that's you, it's okay to say things like, "Hey, we haven't heard from the group "in the corner for a while," or "What does everyone else think about this one?" And also, whether you're a facilitator or not, what you can do is watch to see is there's someone in the room who isn't getting to say what they want.
So, if they are being interrupted, being talked over repeatedly, you can just throw it back to them, like "Hey, Sam, it looked like you wanted "to say something before," or "Hey, I wanted to hear the rest of his point." How about this one? Pitfall number four, it's just the same old problems over and over again.
I spoke to one person about her team's retros and she told me, "We stopped having our retros "because every retro we had, it was just people "talking about bugs that got introduced.
"Every week just this bug, that bug, finger-pointing "at different people and different teams "for introducing bugs, it never changes "and it's bringing everyone down." And what they thought was we're never gonna get rid of bugs, so they got rid of retros. What I told her was remember the retro is about iterating on your process.
Right? You're asking yourself: Is there anything we can change so next week is better? So when these problems are coming up, what you should be doing as a team is looking for ways to fix them.
What we sometimes recommend in situations like this is coming up with a time boxed two-week, is often a good enough amount of time, experiment. Okay, so there's lots of bugs.
Can we try a different way of working for two weeks? Maybe there's a lot of bugs in one particular area of the code base.
Is there something that we can do differently in this part of our work? And just try it for two weeks and see how it goes. At the end of that two weeks we'll have our retro and we'll look at it again and we'll ask: Did it work? If it worked, we'll keep doing it.
If it didn't work, we'll stop and we'll try something else.
And this way you're really facing up to your problems as a team and you're trying things to fix the problems. The team is able to see that something is really being done about it.
So something about action items.
Oh no.
Okay, on action items, make sure that they can be owned and that they're actionable. So you want to actually be able to come back next week and tick it off it it's done.
So for example, keep desks tidier, team.
That's not really a very well phrased action item because next week it's quite hard for me to come back and say whether or not that's been done.
Tidies, what does tidier mean? It's pretty vague.
Who is owning it? Nobody, we've just written team.
A better way to do it will be to say something like, "Okay, what we're gonna do is we're gonna "schedule the time in the calendar every day, "one minute for a desk tidy up, "and Mark is gonna be the person who schedules that." And so next week we'll ask ourselves, "Hey, did that one-minute every day calendar thing, "did that work for us?" Yes or no.
If it worked, we keep doing it.
If it didn't work, we try something else.
But at least you can tick it off.
So I've talked today about retros and I have five final things to leave you with. Do your retros weekly, rain, hail or shine. Don't skip it.
Try to help make it a safe place to be open. Have a facilitator.
Focus on action items and actually make changes off to them.
And the final one is always be kind.
So, probably in your work, in your home, maybe just in your life, it's probably a better way to make the world a little bit nicer.
That's it from me.
But I would love to continue the conversation. Hit me up: Twitter, email, LinkedIn.
Thank you! (applause) (upbeat music)
