Nov
20
Agile Retrospectives: Making Good Teams Great!


ESTHER DERBY: All right, so who
has control of the slides? DIANA LARSEN: Over here. ESTHER DERBY: Do you have
control of them? DIANA LARSEN: I do. ESTHER DERBY: Agile
Retrospectives: Making Good Teams Great. I’m Esther Derby and
I’ve been doing retrospectives for a long time. I have been doing retrospectives
since we used to call them project
retrospective and we would do them at the end of a year-long
marathon project. But that’s not necessarily
the best time to incorporate learning. So since we have been working
in smaller increments, I’ve been doing a lot of work with
agile retrospectives. So Diana and I got together and
wrote this book to share some of what we’ve learned about
doing retrospectives that are small and compact
and are looking at a short period of work. So I will introduce Diana now. This is Diana Larsen. She brings a great wealth of
experience working with teams, working with self-organizing
teams. I first met Diana through a friend who thought
we would have some fun working together. And he turned out to be right. So we’ve been having fun working
together ever since. Did you want to– DIANA LARSEN: Yes, I would like
to introduce my friend and colleague, Esther Derby. We worked on this book for
a couple of years. And during that time,
we pair wrote. We only wrote when we were
in the same room and we had one keyboard. So we tried to incorporate
what we could of agile practices and philosophies
into actually our producing of this book. And so that was a really
valuable experience for us. And every single time we got
together, we got together for week-long increments. At the end of every iteration,
we had a retrospective on what we had done during that time. As Esther said, a colleague
introduced us and his idea was that we would work well together
because he thought we had very complementary skills. And Esther brings to our
collaboration a much longer background in working in
software development. There was a time when she
coded an assembler. ESTHER DERBY: Yeah,
my favorite. DIANA LARSEN: It was
some time ago. However, she also has had the
experience of moving so that one day she was a coder
and the next day she was managing coders. Which is also, an interesting
experience. And from that, started working
a lot with people who were managing software projects and
is also the co-author of a book called Behind Closed Doors
with Johanna Rothman. So wealth of experience and
really delighted to have her as my collaborator. ESTHER DERBY: So I should tell
you that where I come from, if we say something’s interesting,
it’s not necessarily good. It’s like, oh, what an
interesting baby. All right, so enough about us. What about you guys, how
many of you have led retrospectives? A few. How many of you have been
in a retrospective? DIANA LARSEN: More. ESTHER DERBY: Yeah. So what was it like to be
in the retrospective? OK, so five is wonderful and
one is not so great. OK, got a range. We’ve got some four’s, we’ve
got some three’s. Well, hopefully we can
give you some– DIANA LARSEN: I think there’s
one other piece of data left out of that. How many in here have never led
or been in a retrospective and are just here because
you’re curious? ESTHER DERBY: OK. DIANA LARSEN: OK, thank you. ESTHER DERBY: Well, I think
retrospectives are a critical thing to– a critical practice
to bring to agile projects because they are so tied
to the principle of inspect and adapt. We inspect and adapt our code
when we do demonstrations, when we review our code,
when we test our code. We have lots of ways to get
feedback about how our code is doing and inspect and adapt
that, and how our products are doing. And retrospectives are the way
that we inspect and adapt our methods, our engineering
practices, and our teamwork. So it fits right in with that
feedback cycle of looking at what you’re doing, checking to
see if it’s working well for you, if it’s doing what you need
it to do, or whether you need to make some changes, try
some experiments, try doing things a different way. So this is an inspect and adapt
cycle that happens for your methods and your
team work at the end of every iteration. Now, when we were doing long
retrospectives on long projects, we might spend– I think the longest one
I did was four days. Does that sound kind of scary? AUDIENCE: Yes. ESTHER DERBY: Yeah. Well, it was a four year project
where they had worked very, very hard to create the
product that was going to save the company. And after four years, they put
it into their test. It was an embedded system kind of thing. They put it into their test
factory and not a belt moved or a door opened or
a valve changed. So it was a big deal
for that company. I tend to think if they had
been doing retrospectives earlier, they wouldn’t have
found themselves in that fix. But we’re really going to focus
on the retrospectives that you use to look at your
work after an iteration. So how long are your
iterations here? Are you doing one week,
two week iterations? DIANA LARSEN: Two. ESTHER DERBY: One or two
week iterations? OK. Maybe up to 30 days? What’s the longest iteration
you have here? AUDIENCE: Four weeks. ESTHER DERBY: Four weeks? DIANA LARSEN: Four
weeks, yeah. So mostly two weeks,
some four. ESTHER DERBY: OK. So we’re going to cover a
flexible framework that you can use for a very, very short
retrospective, the kind of hour, hour and a half you may
spend at the end of iteration just working with your
team at the end of a week-long iteration. But you could also expand it
to use it on a much longer chunk of work. DIANA LARSEN: There are lots of
books sitting around on the seats of chairs, and you’ll find
this particular graphic in those books. It illustrates that the idea
that this is an ongoing and linked process that just flows
naturally at the end of each iteration, moves right into
the retrospective, and the framework that we are proposing
and that we have found works very, very well for
us– and we’re getting a lot of feedback that says it
works well for other folks– is during that retrospective
we go through five sort of chunks of work that the group
needs to do in order to have a successful retrospective. And the first one is
to set the stage. Now we’re going to talk a little
bit more about that. That’s kind of getting
everybody’s head in the room and doing the things that help
get the thing going. And then, gathering some data. Very often, we start making
decisions about what we want to change or not change about
how we’re doing things without really looking at the data
first. So the data gathering phase is a really
important one. Once we have some data to look
at, data about facts, things that happened during the
iteration, and how we responded to those things
that happened. Then we have the opportunity
to make meaning of it, generate some insights, figure
out, well, what does that mean for us that these things
happened and that we had these responses or reactions? This happened as a
result of that. What does that mean for us? And so we generate
some insights. Then, once we’ve done that, then
we’re really prepared to say, well, so what do we
want to do the same, or differently, or what new things
do we want to try in our next iteration? So then we get to decide
what to do. And oftentimes people jump to
that before they’ve really gathered any data or
made meaning of it. It’s an important part of the
retrospective, but it needs to come after those other phases. And then, once we have decided,
well, so here’s the experiment we’re going to try
in our next iteration. Then it’s time to say, OK, we’re
going to close off this retrospective. It’s the end of this one. It happens in a clean
kind of way. We recap what we’ve decided, we
do a retrospective on the retrospective, figure out how we
might improve that the next time around, and then
we’re done. And then we move right
into the planning part of the next iteration. So it’s a smooth continuum
of flow of work. Right out of the iteration,
iteration demo, into the retrospective, planning, back
into the iteration work. So it just goes on and on. ESTHER DERBY: So speaking of
on and on, sometimes people look at that and they think,
oh my God, this is going to take forever. We don’t have time to spend
that much time. But actually, we find that you
can do these five stages or these five pieces quickly. You can do this in
an hour easily. Sometimes I’ve done it in 15
minutes, depending on what the situation was. But we find that it’s really
important to go through all of those five stages. And if you skip one, you tend to
have either people are not in the room with you or they are
talking from different– everybody’s looking at a
different set of data, everybody’s not on the same
page to use that phrase. Or people may not have decisions
that everyone can support and move forward with. So it sounds like a lot to do,
but it can be done quickly and we find that if you skip
one of these you compromise the results. So we’re going to talk a little
bit about each one of these stages. So set the stage is actually
where you just kind of set the container for the work you’re
going to be doing. So you have a goal. How many of you are using
a goal like continuous improvement or decide what
went differently? Yeah, some of you. How many of you are using a
goal that’s different than that of those who are doing
retrospectives? OK. That’s a reasonable goal to
start out with, let’s look at what’s working and what’s
not working. We find that after a while, that
gets really boring, and people can’t think of anything
else they want to change. So then it’s useful to switch
the goal to maybe looking at our teamwork, looking at how
well we’re applying our coding standards, looking at how well
we’re re-factoring, looking at how well we’re doing
XP practices. So that’s all part of the stage,
is deciding what the goal is for this particular
retrospective. So you have a goal. You have a plan laid out. You tell people what the plan is
because people like to know how they’re going to be
spending their time. And often we do some kind of
check-in, just so people can say a little bit about
what’s going on for them and set it aside. I find check-ins are really
helpful for people to unhook from the stuff that’s been going
on for the rest of their day and just get
into the room. Sometimes we do working
agreements at this point. And this is one of the exercises
we often do as a precursor to working agreements,
which is helping people focus on what ways, the
ways they’re going to interact together that will help them
achieve a really good result out of the retrospective. Has anyone ever been in a
retrospective that kind of turned into a downward cycle
of blame and fighting? Yeah. It can happen if you don’t pay
attention to this stuff. So that’s another reason
to spend some time setting the stage. This is an exercise we do called
Focus On/Focus Off that I’ve kind of previewed
it to FOFO now. Which asks people to look at,
what would it look like if we had an inquiring state
of mind versus we were being an advocacy? What would it look like if we
were trying to be in dialog with the people on our team
rather than debating the people on our team? And use that as a precursor
to help people make some agreements for the time
of the retrospective. They’re not forever. They’re not for the rest of your
life, but just about how we’re going to work together
during this retrospective. We’re tag-teaming it here. DIANA LARSEN: We have our goal,
we have some agreements about how we’re going to work
together, everybody’s head space is in the room now. Now we’re ready to
think together. And that really is what begins
to happen– what’s happening in data gathering. And one of the things that we’ve
noticed a lot in working with agile methods is this is
a very team focused kind of way of going about developing
software. Well, you know, most of us are
trained very well to think and make decisions and gather data
and analyze and all those kinds of things as
an individual. I mean, that’s mostly what our
academics prepare us for. Sharing ideas with someone
sometimes is called cheating in the way we are prepared. But then we get into
the workplace– and particularly in an
agile environment– and we’re expected
to be a group. And so this is where we start
using different kinds of methods and tools to think
together as a group. Which is a different way of
thinking for most of us. And it’s one of the reasons,
I think, that team’s often struggle with doing
processes like retrospectives and planning. It’s because they’re not used
to thinking together. And so, gathering data is one
of the first things we do in this process of really beginning
to think together. So as we gather data, we look
back over the course of the iteration, or the release, or
whatever period of time we’re looking at in the
retrospective. We go back, we use various
methods for this. Sometimes we use a
method called– whoops– a timeline. Where we ask people to
actually, put events. This was a group of folks who
were doing a retrospective over a bigger piece of planning
and three iterations. So they thought back through
what had happened as they did that process and put up the
events that they felt were important to them. So that we had some data, we had
a common understanding of what this project
had been so far. What the work had been so far. Very often, we are all
working heads down. We come to the end of the
iteration and we have very different pictures
of what went on. And so part of the job of the
gather data phase is to make sure we’re all talking
about the same stuff, the same iteration. We all have a fuller picture
of what it actually was. And so we gather data in facts,
like the kinds of events that might have occurred
when people came onto the project. If they came in later, what
different things that might have happened. And then in this one, was added
something called an emotional seismograph. Which is folks went through
and said, here’s what my energy was like over the course
of these iterations. So we look for some way of
gathering some data not only about facts, but
about feelings. But about how we responded to
the events that occurred. ESTHER DERBY: Can I jump
in for just a second? We very rarely use the F word
when we do retrospectives, the “feeling” word. So we may see energy instead
of, how are you feeling? Do you think that would work
well here if you went up to someone and said, how
are you feeling? Maybe, maybe not. DIANA LARSEN: So sometimes
this will be high energy, low energy. Sometimes we’ll use a range for
gathering that data about how satisfied were you with what
was going on during this part of the iteration. There are lots of other ways of
gathering that kind of data without using the F word. ESTHER DERBY: That F word. DIANA LARSEN: That F word. Yeah. ESTHER DERBY: Any F word. DIANA LARSEN: Yeah, we want to
keep– in general, yeah. So that’s what we’re looking for
in the gather data phase. To get a shared a picture of
what really happened during this iteration or this
chunk of time. We have an agreed upon idea now
of what we’re really going to talk about as we go into
the next couple of phases. ESTHER DERBY: We’ve found that
two people can look at the same event and see it very,
very differently. So that’s why that
is so important. After you’ve gathered some data,
then it’s really the time to step back and
do some analysis. So this is the part where you’re
trying to figure out, how did things get to
be the way they are? You know, what were the
underlying causes? What were the patterns? What does this data
tell us about how we’re using our methods? How we’re working together? I think, in general, in US
culture and in engineering cultures, we really
like this part. We really like getting
in there and kind of figuring stuff out. And if we’ve gathered our data,
then the team is more likely to come to some common
and shared understandings rather than advocating for
their own particular interpretation of why things
are the way they are. So this is the part where you
really dig in and you start looking into, what were
the patterns? What may have been the
underlying causes? What are the things that are
keeping the practices in place if we’ve tried to change things
and they don’t change? So there’s a lot of analysis
that goes on in this part of the retrospective to help you
figure out really, why things are the way they are and what
would be a good thing for us to do to change things. So this is a simple method that
we use sometimes in this part of the retrospective. We call this the learning matrix
and we just divide a sheet of paper in four things. And at the top are what
went well and what didn’t go so well. What we would want to
do differently. Which are questions that show up
in a lot of retrospectives. Sometimes they’re the only
questions in a retrospective. And we find that when
retrospectives start there, they tend to get fairly
superficial insights. But if you’ve gone through the
gathering some data, you tend to get a better level
of insight here. On the bottom part of it are
ideas of things we could do differently. And that’s a little
bouquet there. If there’s someone you want to
hand a bouquet because they did something that really
helped the team. So this is a quick way to do the
generating insights phase of a retrospective. DIANA LARSEN: So when we have a
shared picture of what went on during our work together,
when we’ve made some meaning out of that, we’re ready then to
say, OK, what do we want to do with this? What direction does
this send us in? What concrete actions
do we want to take? And those can come in a number
of different flavors. It might be things that we’ve
been doing that we don’t ever want to do again. We don’t want that outcome
ever to happen again. And we’ve done some analysis
about why it happened, and so we want to shift that. We want to do something
different in that arena. It may be that we want to
adjust it in some way. We want to just refine. It may be that there’s been
something going on during the time that we’ve been working
together that has actually contributed a lot to our
success, but we’re taking it for granted. And so we need to actually pay
some attention to it and ensure that it continues. I was actually talking with
someone earlier this week about a project that they were
on where they had been doing some things that were really
helpful to them. And over time, they got a little
smug about it and they just stopped paying attention
to some of those things. And they started noticing
that their productivity was degrading. They chose to have a
retrospective where they focused on that. That solely was their goal. Why are these things not
happening anymore that used to happen? That was the goal
that they chose. And out of that, they discovered
we weren’t paying attention to these things that
were making us successful. So we want to look at a number
of different things and then make some choices about, what
is it we want to do in the next iteration that we think
will help to make things better around our goal? Whatever our goal might be. We really suggest that teams
don’t take on too much. I mean, if you’ve a two
week iteration– some teams have one
week iterations– you can’t have 10 improvement
plans. You’d never get any other
work done, right? So you need to pick the one
or two, or maybe three. And that’s a big stretch. Really one or two things that
as a group the team thinks would really help them
the next time. Or just an experiment that
they want to try. This is how some teams begin
to add in some of the XP engineering practices. They’ll say, well you know,
based on some of the things that happened this last time,
I think if we gave more attention to formally making
sure that we’re pairing together and making sure that
we’re all doing that on a consistent basis. Because now it’s kind of
catch us, catch can. And we think we’d do better if
more of us were pairing. So that might be the piece
that you take on, the experiment that you try. And it’s just an experiment. And at the end of the iteration,
have another retrospective. You have an opportunity to
assess how did that go. So then deciding what to do is
where we make some choices about, what are we going to do
in the next iteration that we think is going to help? Very often, it’s just
ideas go up. And in this instance, we’ve done
just voting with dots. And this team has made
some choices about– you know, that they’re going to
go with whichever ideas get the highest votes. That’s how they’re
going to decide. It’s just kind of a majority
rules kind of thing or an energy rules because I think
these people all got more than one dot when they voted. But they made a decision. They made a decision as a
group that they were all willing to support about what
they’re going to do in the next iteration that they think
is going to continue to improve how their
work gets done. ESTHER DERBY: I just want to add
one little subtlety about prioritizing. I have noticed that depending
on how you ask the question, you get very different
results. Like if you say, what’s most
important for us to do? You may get one set
of results. People will look at the list and
say, well, really, this is most important. And then sometimes, it
doesn’t get done. But if you ask, what will have
the biggest effect on us? Or what do we have the
most energy for? You tend to get an agreement on
something that people are going to have a little
more commitment to follow through on. Had to add. I just had to add that. The final part of a
retrospective is actually closing the retrospective. And I find that it’s important
and helpful to do this decisively rather than just kind
of letting things dribble away, and go off into
another meeting. So you end it decisively by
saying we’re at the end of our retrospective. I would like to appreciate you
for all your hard work. Decide how you’re going
to follow-up. Do a retrospective on the
retrospective and close. Before I go into this, I want
to say something about what you do to follow-up. I’ve talked to people who
say that they did some retrospectives, but nothing
ever changed. You know, we came up with all
these great ideas and we had this plan, and nothing
ever changed. And when I asked some more
questions, I usually find out that that’s because either they
had no way to follow up or, even more commonly, they
had a separate improvement plan that lived over
there somewhere. And when you have a separate
improvement plan, it almost never gets incorporated
into the work of developing software. Because people are focusing
on doing that. So that piece of follow-up about
we’re going to take our plans into our iteration
planning meeting, I think is a critical thing for actually
having retrospectives that get some results. This is one way that we do
a retrospective on a retrospective. And this is actually useful for
any kind of meeting you have or working session. And it’s measuring return
on time invested. So you’ve invested an hour
in this retrospective. Did you get a high return on
the time you invested? Was it a break even? That for an hour you feel like
you got an hour’s worth of insight or benefit out of it? And on zero is this is an hour
of my life I’m not going to get back and I felt like
it was wasted. So this is a way that you can
look at how much value people are finding in your
retrospectives and get some ideas about how to change. I would follow this up by
asking, what specifically would have made this a more
valuable meaning for you? You know, when I do this kind
of ROTI gauge, I’m satisfied if people are at
a two or above. You know, two is break-even. You know, I invested an hour,
I got an hour worth of benefit out of it. That’s fine with me. If someone got a zero, then
I’d want to know. And sometimes it’s not about
what you, as a retrospective leader, did. Sometimes it was that I was so
distracted by some other stuff going on that I just really
couldn’t participate. So it may not be a reflection
on you. It may just be a reflection
of what’s going on. But there are a number of ways
that you can look back at your retrospective and figure out
how to make them better. In the spirit of continuous
improvement. And it doesn’t have
to take long. That goes quite quickly. DIANA LARSEN: So we do start
doing retrospectives on a regular basis. We don’t just wait til the
end of the project to do one big one. At which point, it’s too late
to do anything about that project anyway. We decide we’re going to commit
to doing them every iteration, every release, and
what will we get from that? We actually went out and polled
some of our colleagues who work inside big
organizations and asked them, what kind of results are
you getting from the retrospectives you are leading
and from the retrospectives other people in your
organization are leading that you’ve trained in
that process? And these are the things
that they told us. And there are some really big
companies whose names we unfortunately are not free to
mention who have actually collected some data on
these dimensions. But what they tell us is they
get improved productivity. People know what it is
they want to do. They continue to make
improvements and changes. They get into a continuous
improvement state of mind. And things continually
get better. Not always in a smooth curve,
but over time they see that when they’ve installed
retrospectives as a regular part of how the project gets
done, they start seeing that people are just able to
be more productive. They understand how they
fit in the team. They understand what
the work is. They understand what they’re
going to do. Also, it improves capability. And that’s because in
a retrospective, you begin to talk– in that gathering data phase
where people are talking about how they have different
perspectives on what happened during the iteration. People begin to be able to see
things through different eyes. Through not only their own
experience of the iteration, but through that of
other folks too. And that helps them begin to
take on some additional capabilities. They can see the world in
a broader kind of way. Also, as of the result of some
of the experiments that teams choose to do, it causes
an increase in capability on the team. We’ve had a number
of teams who’ve– as you may have noticed in
the one illustration. Teams who say, we really
want to focus on sharing our learning. If I read a book or if I go to
a training class, I want to make sure I come back and give
a brown bag to my team, and make sure that I transmit
that information. That also feeds into improving
capability. Improving quality, all feedback
loops help to improve the quality of both quality
of work life and quality of product. Increased capacity. Teams that are doing
retrospectives, it’s one of those sort of counter-intuitive
kinds of things that when they take time
away from the work to do a retrospective, they actually
end up getting more work done. So their capacity increases. And in general, because of these
regular sort of timeouts to examine, how is our
team work going? How are our methods going? Are our processes
working for us? Taking the time to do that
builds trust and morale in the teams. So this is what we get when we
do regular retrospectives. You may not get it out of the
first one, or even out of the first two that you do. But when they become a regular
part of how a project is accomplished, then we begin to
see these kinds of benefits. ESTHER DERBY: So we talk a
little bit a few minutes ago on the decide what to do slide
about actually getting results out of a retrospective. And one way to do that is to
make sure that the plans are incorporated into the day to
day work plan, so it’s not some separate improvement plan
over here, or separate experiment plan over here. It’s just we’re going to do
one thing in the next iteration, or maybe two
things in the next iteration, to get better. So that’s a key thing
you can do. But then you have to
support change. We find that when people are
learning any new skill or going through any change,
they need a few things to help them along. They need reinforcement. So they need to have that goal
in front of them to know that this is why we’re going
through the pain of making a change. This is why we’re going through
the disruption of it. They need empathy to acknowledge
that change can be difficult and change
can be hard. So it’s not the pull up your
socks and buck up and get with the program. It’s just acknowledging that
change can be difficult. People need opportunities to
learn and try out the new things that they have decided
they’re going to incorporate into the way they’re working. So they need opportunities to
actually get the information, get the skills, and
then practice. Because we all need to practice
in order to learn anything new. I think most of us recognize
that if we’re learning a new sport, we aren’t going to do it
perfectly the first time. But somehow, when we learn
intellectual things or skill things, we often feel like,
well, we went to class. We should know how to do it. But in reality, it
takes practice. So to support people through
change, we need to give them opportunities to practice. People need reminders because
people will fall back into their old habits. So if your team has agreed that
on this iteration we are really going to become much
more systematic about re-factoring, people may need
some reminders that, hey, we agreed that we were going to
re-factor, so we can’t let that slide. So little reminders to help
people build that new habit into their business as usual,
kind of this is how we do things around here. DIANA LARSEN: One of the
techniques that we hear about a lot in agile teams are called
big visible charts. And big visible charts can
work very well as both reinforcers and reminders of
what people have chosen to do in their next iteration. ESTHER DERBY: And sharing
responsibility. A trap that I see a lot on
retrospectives is that the coach, the agile coach, or the
manager, or the project manager, will say, oh, well
that’s my problem to solve. And oh, I’ll take
care of that. And oh, that’s on my list.
And they suck up all the responsibility for making
all the changes. And either they get overwhelmed
and nothing gets done or they set up a dynamic
where the team doesn’t believe anymore that they can actually
act on their own behalf and make their own work
like better. So I think it’s really important
in retrospectives to make sure that it’s not just
one person who takes responsibility for change. Sometimes it’s the most senior
developer that will take all the responsibility. But I think it’s really
critical that that responsibility be shared. OK, now what? People often ask us, what’s the
best retrospective you’ve ever been in? So what’s the best retrospective
you’ve ever been in, your favorite
retrospective? DIANA LARSEN: My favorite
retrospective? Well, I’m kind of a
large group geek. I like working with
very large groups. And so I had the opportunity one
time to do a retrospective with 75 people in the room. And that was really fun. It was really fun. And I was looking at a
really big project. It actually had been a two and
a half year project that had 300 people on it. So the 75 were sort of a
representative sample of all the different functions and
different folks, different areas that folks had– job areas that folks had
done on the team. And they chose to really
focus on how to replicate their success. Because they had created a
really marvelous product that everybody thought was really
cool by the time they got to the end. And so it was a very
fun retrospective. It was one of my high points. What about you, Esther? ESTHER DERBY: Well, you know,
I hate to choose just one. DIANA LARSEN: I know,
it’s hard. ESTHER DERBY: It’s hard. My favorite today, it might be
a different one tomorrow. But my favorite one today is one
where the developers had kind of known all along
that this project wasn’t going anywhere. But management was so intent on
believing that it was going to work that they could listen
for whatever reason. And by the time we got to the
retrospective, that group, the developers, were so angry that
they were just spitting. They were just loaded for
bear and wanted to go after the managers. So I sent the managers off into
another room to work on an activity and I sat with the
developers and talked to them about what their experience
had been and how it felt to them. And they went from being
very angry and very– just saying some really, really
nasty things about those managers that I cannot
repeat in this room to making just a very strong statement
about we are professionals. We will do our best to give
you reliable information. We will tell you about our
progress in these ways. And we expect in return that
you’ll listen to it. So they just made a really
strong statement about we are competent, capable, intelligent
people. This is how we are going to
contribute to the success. This is what we expect
from you. And it was just a huge shift. And they went from being angry
and beaten down to saying, you know, we’re not going to
let this happen again. And we can talk about it in a
way that’s respectful of us and respectful of
other people. So that’s my favorite today. DIANA LARSEN: So those of you
have either led retrospectives or participated in one, or more,
who has a high point that you would like to share? We have a microphone in the
middle of the room here. Who has a high point? This group could
use some work. I have, actually another high
point that I really like– ESTHER DERBY: How come
I only got one. DIANA LARSEN: Well, I’ll give
you another one if you want. You can have several
lows if you like. And actually, it’s an anecdote
that shows up in the book. Where during a retrospective, we
did a timeline and in that one we gathered that sort of
response, reaction data using sticky dots. We put sticky dots on the
different events. And in that one I asked them to
put one color of dot on if they thought this was something
that happened that really helped the team during
that period of time and another color of dot if they
thought it was something that really was kind of a crisis
or didn’t work so well for the team. And there was this one card that
had like all but one of the dots on it were this
was a great thing. And the one dot said, no,
this was terrible. And so I just asked, what’s
going on here? And it turned out that one of
the people on the team, a young woman on the team, and at
one of the daily meetings, had just blown up about
something that she had been– ESTHER DERBY: Excuse me, I’m
going to go deal with the technology. DIANA LARSEN: OK. That she had been holding
in for some time. And she thought that it really
was disruptive to the team that she had finally said this
thing that had been just– she had been holding in. And the rest of the team
thought it was great. And watching the transformation
of what happened in that team as they
told her why that was so valuable to them that she
actually just said what she thought finally. And her hearing that what she
had to say on the team was valued and was worthwhile was
a pretty amazing moment. ESTHER DERBY: And a perfect
illustration of why it’s important to gather data. DIANA LARSEN: Yeah. ESTHER DERBY: All right, so
I think we’re going to the next one now. DIANA LARSEN: Next one, yeah. ESTHER DERBY: Oh, low points. DIANA LARSEN: In the desert
of the low points. ESTHER DERBY: In the desert,
stranded in your wagon with nothing to pull it. What’s your low point, Diana? DIANA LARSEN: My low point is
a time in a retrospective when– it was very similar to
what you were just talking about earlier. When I was in a retrospective
and this team had come up with way too many process
improvements that they wanted to make. And one person on the team kept
saying, I want to take care of that. I want to take care of that. I want to take care of that. And I kept asking, are you sure
that this is the best way to do that? And there was no way
I could budge them. Nor could budge her, who was
taking on all this stuff. And I kept saying, what are
you going to take off your plate if you’re putting
all these things on? Nothing. So we walked out of there and I
had the feeling that things weren’t going to go– the improvements were
not going to happen. And sure enough when I checked
in about six weeks later with the person that had been my
contact there and said, what’s going on? And he said, well, this woman
had– not much had happened because this woman had burnt
out and left the company. There wasn’t any way for people
to pick up all those things that she said she
was going to do. So that felt pretty icky. It felt like they’d done a lot
of work and didn’t get as much value for it as I would have
liked to seen them got. They did actually
made a couple of improvements out of it. That were things other people
said they would do. But the whole long list of
things she had they didn’t do. ESTHER DERBY: What about
the one where the facilitator was– the person leading the
retrospective was– DIANA LARSEN: Yeah,
that was hard. That was one I was in. I was in a retrospective,
someone else was leading it, and it was a brainstorming
session. And as people called things
out to be recorded, he was writing down what he wanted to
write down instead of what people were saying. And that was pretty
frustrating. ESTHER DERBY: It was kind
of astonishing. I was in the same
retrospective. It was kind of astonishing. And not very satisfying
and nothing happened. Surprise. DIANA LARSEN: So we’d love to
hear your low point stories. ESTHER DERBY: No, I get to
tell a low point now. DIANA LARSEN: I know,
but I just wanted– just before they get
too excited about their low point stories. We want to hear yours too. But I’m noticing the time. So we’ll hear Esther’s and then
maybe we can hear your low point stories
later on today. ESTHER DERBY: And give you
some ideas on how– DIANA LARSEN: And give you
some ideas about how to adjust. ESTHER DERBY: How you could
address a situation like that. All right, so my low point. I was in a big retrospective
with– you know, I think there were
30 people who had worked on this iteration. It was the end of a release,
so it was like, two months worth of work. One of the things I sometimes
do in retrospectives is an activity called appreciations. Where people just take a minute
to say something that someone has done that
really helped them. So people were doing that. People think engineers won’t
like that, but my experience is they almost always do. So it started a little slow, but
then people started really liking it and they were saying
how I appreciated that you helped me find that bug. And I appreciated that you
helped me learn how to use this particular– and the sponsor of the
retrospective stood up and said, the wrong people
are being appreciated in this room. And stormed out. It’s like one of those moments
where you say, oh my goodness. Whatever do I do now? I took a few deep breaths and
I said, what just happened? And the people in the
room said, oh, she’s like that a lot. I thought, oh well, this
explains much about this organization. So again, I gave them a task to
do and they said, she’ll be in the ladies’ room sulking. So I had to go off to the
ladies’ room and have a chat. And I don’t know what I would
have done if it had been the men’s room. But I might have gone
in and had a chat. I might have. You know, just
put a sign up on the door, out of order. Don’t come in. And gone in and had the chat. So we had a chat and then it
surfaced a bunch of other stuff that was going on with
the management team there. Which we then worked on and
things got a little better. But you know, hey, I lived. And chances are that sooner
or later if you do retrospectives, you’ll run into
something that’s a little distressing and not quite
what you anticipated. But you’ll live through it. You live through it. DIANA LARSEN: You get over it. ESTHER DERBY: And you
get to tell stories. DIANA LARSEN: Then you have
great stories to tell. So this has been a pretty fast
and high-level overview of what we think of as really
important things to think about when you’re
thinking about working in agile practices. I blogged on this a
little while back. I have a feeling that if any
team that was really focused on continually improving their
methods and their teamwork and that was in an atmosphere,
a company that supported learning, and they did regular
retrospectives, I think sooner or later they’d sort of invent
most of the agile practices on their own. But that’s just me. So I think it’s very central
to, as Esther said earlier, it’s a part of the inspect
and adapt cycle. You really can’t be agile doing
agile methods using these philosophies and practices
if you’re not inspecting and adapting
all of it. And the retrospective is the
best tool I know for inspecting and adapting
methods and teamwork and processes. So just want to leave you with
a thought about what one thing, if you could just change
one thing about your retrospective so that you think
you would just get a little more value out of them,
what would that one thing be? What would that one thing be? ESTHER DERBY: Maye it’s
have [UNINTELLIGIBLE]. DIANA LARSEN: Don’t try to
do a wholesale thing. Just one thought. DAVE: Start doing them. DIANA LARSEN: Start doing
them is a good one. Thank you, Dave. Yeah. But there might be others. For those of you who are already
doing them, there might be something that you want
to– a little increment you want to tweak. So we want to leave you
with that thought. And thank you for your time. ESTHER DERBY: Yes, thank
you so much. DIANA LARSEN: I’m delighted
to have all of you show up with us. ESTHER DERBY: And we
will be at the– what are we going to be at? AUDIENCE: It’s room
[UNINTELLIGIBLE] over there from 4:00 to
5:00 in one hour. ESTHER DERBY: So if you have
other questions or want to generate some ideas about how
you can work with your retrospectives, we’d be
happy to talk to you. DIANA LARSEN: Thank you.