Matt Grommes wrote another thought-provoker today on sprint retrospectives; my comments started wandering and found their way into this post...

The few retrospectives I've facilitated have taught me a few tricks.  Matt is correct when he says that a retrospective can turn into monster vetching session if allowed to do so.  In my opinion there are two keys to avoiding this:

1. provide a structured way for the team to express their input;
2. timebox everything. 
   

I've found the following retrospective structure to be effective in producing actionable feedback....

Prerequisites

I show up to facilitate a retrospective armed with the following items:

• a white board with working markers and an eraser;
• green, pink, and yellow post-its;
• pens;
• a kitchen timer;

Sometimes I bring a yummy treat, but I've had that backfire when the sugar rush ebbs and the team starts to wander mentally.  I also try to schedule the retrospective as the last event in the workday for everybody, but early in the week.  This seems to keep the team at ease, but focused.

First: Establish Trust in the Process

Like confessions extracted under coercion, feedback is worthless when obtained from someone who doesn't feel secure enough to be honest.  Agile processes in general rely heavily on open communication, and I found that my non-agile team displayed a lot of mistrust in the retrospective's goals.  

I begin each retrospective with a technique described in Agile Retrospectives: Making Good Teams Great that is aimed at measuring the willingness of the group to communicate.  Each person writes on a post-it a number between one and five inclusive, indicating their willingness to participate in the discussion to follow:

1. I will not speak;
2. I will be quiet and let others talk;
3. Some things I will discuss, some things I will not;
4. I'll talk about almost anything;
5. I'll talk about anything.

The anonymous post-its are collected, tallied, and discussed briefly.  Obviously the goal is to have all fives, maybe one or two fours in the mix.  The times I've seen anything else, it's either because a communication problem exists on the team, or the goal of the retrospective is in question (e.g., QA feels like they will be scapegoated for a missed deadline).  

I keep discussion to five minutes, reiterating the retrospective Prime Directive, making sure that everyone knows they are expected to keep the conversation productive, and that the goal is to make the team work together better.

Second: Discuss Good Things

Next I pass out the green post-its and pens, and ask everyone to write down as many things as they can think of that worked well during the sprint.  I ask them to include team and personal efforts,  new or existing processes, anything they can think of that made a positive contribution to the effort.  I use the timer to box the task to 5 minutes.  

I collect the anonymous post-its and start going through them one at a time, collating as necessary.  I read each Good Thing aloud and open the floor for discussion.  I try my best to categorize them on the whiteboard as we go, so the team can see common trends.  For example, several post-its may comment on positive effects realized in documentation and QA from adding a bit of structure to the developer's subversion commit notes.

This part of the retrospective is generally pretty easy.  There isn't a lot of gray area in terms of choosing to maintain a practice that has a positive effect on the team. In addition, I find that discussing the positives first helps the team open up more during the next task...

Third: Collect and Categorize Bad Things

I pass out the pink post-its, set the timer for 5 minutes, and have the team jot down anything they felt impeded their work.  I emphasize "anything" - I would rather someone write down 10 also-rans and 2 gems than to spend the entire time deliberating on what to write at all.  

Against the advice of most retrospective experts, I ask the team *not* to exclude personal remarks about other team members; however, I do remind them that the remarks should be constructive, and that the retrospective is not a performance review.  For example, I would consider this appropriate:

Jim would benefit from writing more unit tests, having regular peer reviews, and mentoring.

but this inappropriate:

Jim's code sucks and never works.

As usual, I collect the post-its anonymously (I like to use a coffee can with a slit in the lid, BTW), during which time I draw two columns on the whiteboard: "Under Our Control" and "Out of Our Control".  I read each Bad Thing aloud and ask the team a single question:

Do we have control over this?

Their answer is usually unanimous, and it dictates which column the post-it falls on the white board.  There is no discussion of the Bad Thing at the point - the purpose of this task is only to isolate whether the Bad Thing is something team can fix themselves. 

Finally: Discuss Solutions and Take Action

Once the team can see what they can control and what they can't, the discussion can begin.  I spend a few minutes on the "Out of Our Control" items, but only to alleviate fears and to keep the discussion solution-focused and positive; I then remove those items from the board.

Moving on to the remaining post-its classified as "Under Team Control," I align them down the left side of the board in no particular order and draw racing lanes across the board for each.  I then ask the team which Bad Thing they believe had the most negative impact on their work, and we start the discussion there.

This is the part where I find the role of facilitator to be most important. It is very easy for the team to drift off-topic, or for to get bogged down in complicated solutions to simple problems.  I find it helps to focus discussion by reiterating one simple question:

What can we do today to prevent the Bad Thing from happening tomorrow?

Most of the time the team will produce a viable solution.  If the team can't gel on a fix, I pass out the yellow post-its, we storm out fixes for a few minutes, collate them in the racing lane, and then discuss.  The point is to keep the conversation on-target and constantly moving forward.  Once the team settles on a solution, I jot down the actionable items in the racing lane.

I repeat this process for each Bad Thing, allowing the team to choose the ordering, spending at most 10 minutes on each one.  If we get through them all in the retrospective's timebox, I'll open the floor to general discussion; however, my experience is that there is little else to discuss at that point if I've done my job.

Offline: Summarize and Reiterate the Solutions

Once the retrospective is over, I write up a short summary.  I list all the Good Things, and all the Bad Things and their proposed solutions.  I send this out to everyone involved, both pigs and chickens.  I also keep a copy handy to remind myself and others of the specific commitments we made as a team to better ourselves.

So there you have it Matt.  In my limited experience, what I find makes an effective retrospective is lots of structure to focus the team on one thing at a time and curb the naturally vetching tendencies.

I've been following a very interesting series of posts (starting here) from Matt Grommes detailing his experiences managing his first agile project; today he posted a sort of team retrospective.  Having cataloged my own successes and failures during by brief attempt at agile project management, I was eager to see how Matt's experiences compared to my own.  I was surprised to see that the problems he lists are either identical or orthogonal to mine (I was expecting one or the other, but not both).  For instance, Matt found as I did that keeping the backlog tasks and estimates accurate became an issue as the sprint wore on, and that failing to discuss and estimate the product backlog caused significant problems.  But while Matt's team concludes they did too much planning up-front and not enough later, but I think we had too little forethought and too much ad hoc cram-it-in work later.

In any event, Matt seems to have at least one very good thing going for him: his team is committed to improving themselves.  I hate to admit it, but we've reverted to the neverending ground-and-pound routine we've been maintaining for almost four years now.  We calling it "scrum," but I know it's not scrum and it's not agile because these things give it away:

• we rarely estimate anything, we just beat on features and bugs until they're completed;
• we almost always miss deadlines, which are fairly arbitrary anyway due to the lack of estimations;
• we don't have much "team spirit" - or perhaps I'm simply excluded from it.  Instead specific indivuals are recognized as the owners of various parts of the system, and it's a bit of a political battle to be involved outside of your sandbox;
• we generally have four or five projects ongoing, with team focus split between several of them at any given time;
• we don't iterate or increment, we go dark for weeks, develop like madmen, and throw it over the wall to QA when we're done;
• we don't retrospect projects anymore, we move immediately to the next project without discussing what worked or didn't work so things get better over time.
  

I find it odd that we would shun the beneficial aspects of scrum and agile - the transparency of our work, clarity of tasks, the focus on communication, the postponement of details, the sharing of labor, the confidence of cycles, the leverage of teamwork, the push to improve the team - while at the same time embracing a commitment to work full throttle to meet a deadline.

Well, good luck with it Matt, and keeps those posts coming - seems to me like y'all are off to a good start.

We had a lot of problems trying to use user stories as the basis for a product backlog.  We haven't had a retrospective yet, and I anticipate having to wear my asbestos boxers for that wondrous event; however, I have noticed that some of the bigger picture aspects of what I tried to accomplish have established roots in the team.

Phrasing Requirements

One of the things I kept beating into the team's head was Mike Cohn's user story template: 

"As a <user role>, I want to <feature activity> so I can <value achieved>."

Sticking to this template helped us in many ways:

• it pushed the team into thinking from the user's perspective, which greatly improved our ability to communicate about the feature by having a common, iconic user to reference;
• it forced a value statement for every feature, which made blatantly evident the features that were also-rans;
• it made creating acceptance tests a breeze.

Several other projects have flared up at the office, and what I'm seeing is the product owners continuing to use this template to communicate their requirements.  That means better discussion and more acceptance testing.  That makes me happy.

The Need for Accountability

One of the points of using user stories as the product backlog was to enable the team to develop vertical slices through the system - get a single feature working end-to-end - rather than horizontal slices - building up an entire system layer, such as a database or front-end in isolation.  I wanted a cycle of feedback for the team, get a feature into QA for testing, in front of the stakeholders for comment, back to the developers for refinement.  The softer side of the team - by that I mean the product owner and customer representatives - wanted that too.  But the vertical development never happened.  The developers simply would have no part of it, citing various reasons that are locally valid but miss the global point.  Instead, they chose to work on horizontal layers of the system.  Milestones came and went, no features were evident, and QA was sitting on their hands for over three weeks.

The stakeholders brought up the notion of recourse: how would development be held accountable for the missed milestones?  The answer, much to my chagrin, was that they would not.  There is no delicate way to explain the situation, but it may help to understand that the efforts of the developers were praised by their senior manager.  

I've been reeling over this for a week now, my eyes bloodshot from searching for a positive in this dim and ugly situation, and the thing I keep coming back to is this notion of transparency.  Everyone - the team, the stakeholders, and the innocent by-standers - knows why milestones were missed.  So at least we can collectively acknowledge the situation, and that there is a need for holding the team accountable for disrupting the feedback loop.

Or not, depending on the way the wind blows... 

As recounted here, I had the team circle the wagons and pump out a bunch of user stories for an integration project.  It was the first time we'd tried user stories as a means to express requirements, but things felt solid and complete, and the product backlog was full of stories organized by system component and user role, perfect for developing in vertical slices. 

The project was considered top-priority and had the undivided attention of the company for the time being.  In the rush, I skipped estimating the backlog items and scheduled the sprint kickoff meetings.

Over the product backlog meeting, we iterated through each user story, reading it aloud and discussing in enough detail so everyone understood the feature and the value it brings to the user, but leaving out implementation discussions.  At least, that was my expectation.  The team members uninitiated in the project got flustered with the lack of specificity in the stories.  Some team members seemed to panic, like we had missed a big part of the picture; others got frustrated at the level of intimidation in the room.

The sprint kickoff was a bazillion times worse.  During the product backlog meeting, the product owner hadn't expressed a desire to see a specific set of user stories first, so individuals took the sprint kickoff in their own direction and were adamant to work on features that were obsoleted or purposefully left out of the product backlog.  There was no common ground to be found.  At the end of that sprint kickoff meeting the team had no goal, no milestones, no tasks ... we couldn't even set up the time for our daily scrum.

I've spent a lot of time decrypting what exactly happened.   There were things under my influence, and others outside of my control.  Here's where I think I failed, and what I've taken away from it....

Failure: The product backlog meeting was the first time the entire team had come together to discuss the project.  In particular, it was the first time any of the developers were exposed to the feature list.

Lesson: Expose representatives from each team to the relevant product backlog / user stories before the kickoff.

Lesson: Have the team estimate the complexity of each story, to elicit discussion if nothing else.  Ensure that representatives from development and testing are present.

This seems really obvious, but after a week of daily 3- to 4-hour story workshops I was feeling like the team was familiar with the stories.  Usually there is a lot more effort put on the product backlog than what we did for this project.  The product backlog should be treated like a pet requiring daily attention and affection to remain healthy, but instead we just chain it outside with an open bag of food.  Consider that the team would normally help the stakeholders evaluate priorities by providing rough estimates of the stories in the product backlog.  If one story has a high business value but would take 6 weeks of work, while 3 stories with a greater total value would take one week of work, it may make more sense to tackle the 3 stories in one week first.  Congealing the team on those estimates requires discussion of the features.  We didn't do this estimation because of time pressures - but in so doing (or, I guess, in so not doing), we neglected ourselves of that vital team conversation.

Failure: The user stories varied in specificity from hazy to anal; some overlapped each other; some were really just acceptance test criteria for another story.

Lesson: Focus each story on a user role, a feature, and a business value.  Don't repeat the combination in another story.

Lesson: Express detail and acceptance test criteria as story notes, not as separate stories.

Lesson: Spend the time to refactor the stories and organize the product backlog.

A lot of the frustration in the product backlog meeting stemmed from the fact that some features had a single story, while others had multiple stories, all of them nearly identical save one bit of detail or acceptance criteria.  The perception was that little to no thought had been given to those sparse stories.  I think most, but not all, of this frustration could have been avoided if I had worked with the product owner and customer representative to consolidate and organize the stories before bringing them to the team.

Failure: The sprint kickoff meeting started with a goal vacuum.

Lesson: Force the product owner to prioritize milestones for the sprint before the product backog meeting.

After all, that's the point of the product backlog meeting, right?  To get the team to commit to a specific set of goals delivered at a fixed time.  Not having that goal means the story buffet is open, and each team member will want to do what they think is the most important thing on that backlog.

And last in my list, but certainly not the last mistake I made...

Failure: While the testing, customer representative, and product owner understood the nature of this new user story beastie, the development team did not.

Lesson: If you expect the team to participate in a new thing, make sure they understand its nature.

It's completely reasonable for someone to get frustrated with a process if their expectations of the process haven't been managed.  If I had simply reiterated to the development team that these stories were really placeholders for conversations about the feature that we'd have during the sprint kickoff, it probably would have stemmed a lot of the frustration at the product backlog meeting.  

All in all, it isn't just vinegar; a lot of sugar came out of us trying user stores, which I'll explain in pt3: Two Steps Forward.