Wayne State Web Team

Wayne State University Web Team Blog

Why we retrospective

The best tool a team can have is the ability to analyze and adapt. The last few weeks I have been talking a lot about Agile agile practices. I intentionally use the lowercase "A" because I am not advocating for any specific methodology but instead to use the Agile Manifesto (opens new window) at its core and use team "agility" to find the best practices for your team.

This process starts with the 'retrospective (opens new window)', which is adopted from the 'Scrum (opens new window)' methodology but is used to look back at a period of time, usually one or two weeks, and introduce a feedback loop for the team to discuss and improve. This is the foundation to critically analyze processes and goals.

This is the basis for a talk (opens new window) I have adapted twice (opens new window), with more iterations coming in the next few months. Retrospectives are just one topic in the talk but it's the foundation for the rest. The higher education specific (opens new window) version is below.

# Highedweb Michigan presentation

When a team has an existing process, it can be uncomfortable for some people to change, especially if something isn't going 'horribly wrong' and thus is less apparent. But we all have room for improvement as long as we are willing to try.

# All team buy-in

Everyone must be willing to try ideas for some time before dismissing them. If the entire team isn't on board, the reflection and process planning won't result in the best possible solution. The team shouldn't dismiss even the most out of the box ideas unless they try them for some time, one or more weeks. If the change totally fails, no one likes it or it doesn't produce the desired results, that will come out in the next retrospective and everyone will agree to go back or adapt what was tried.

# Start with your current process

Don't change a thing in the beginning, just talk. You may find that a two,three hour argument discussion may take place the first few retro's. This is good, it may not feel like it's producing anything productive, but these feelings, ideas and issues need a vehicle to get addressed and out of the way before real improvement can happen. You'll find that other members of the team may be very passionate about the same things you are, but you may never have noticed. Over time the retrospectives will become shorter and more productive. Hang in there.

# Running a retrospective

First rule: No technology during the retrospective, everyone take out their phone and place it in the middle of the table. This may get people squirming at first but giving all team members the equal respect of your attention makes a world of difference.

Next, there needs to be a facilitator, this can be someone on the team or someone external. Their role is to keep everyone on track and to record the discussion points.

Then, go around the room and have each person answer the following questions:

  • What went well?
  • What didn’t go so well?
  • What have I learned?
  • What still puzzles me?

Our team also adds the question, "How stressed were you on a scale of 1-10?" We make it a point to focus the changes for the next iteration on reducing the number for the most stressed person.

# Discussion

After everyone goes around and the team has heard how the last week or two went, only then can an effective discussion happen about what should stay the same and can be improved. As a group, although it shouldn't be limited to an unanimous vote, everyone should agree (or be willing to try) what to change over the next week or two (depending on how often retrospectives are done).

The facilitator has the job of moving the discussion along and ensuring comments are moving in a productive direction. Discussions that get out of hand for a few minutes are fine, but make sure it doesn't diverge into complaining about a person or process that the team doesn't have the ability to improve.

# Change just one thing

Like any iterative process, it is important to change just one thing at a time, or at least one thing per area. Depending on the size of the team and who/what they interact with, more than one change can happen, just make sure it isn't too much to keep track of. But document the changes and determine when it should be revisited.

# Iterate, rinse, and repeat

At the end of the day being happy working on meaningful work that makes an impact is the ultimate goal. If you're not moving in the direction, bring it up in your next retrospective.