Let’s Take It To The Parking Lot

Last week, I was facilitated a retrospective where we focused on meeting satisfaction. While talking about the daily scrum and what could be improved, an engineer brought up the team’s use of the “parking lot”.

If you’re not familiar with the “parking lot”, it’s used when a discussion is going a bit too deep, taking the team off track and not applying to everyone. Saying “put it in the parking lot” means that those concerned can have a separate discussion after the meeting. Similar to the classic business cliche of taking it “offline”.

Back to the retrospective… the individual rightly mentioned that when the daily scrum ends and transitions to the parking lot, the team typically remains in place, listening to the parking lot discussions. So, the parking lot essentially becomes an extension of the daily scrum. In addition to that, the engineer’s desk is adjacent to where the team stands, so he has to wait until everyone leaves so he can take his seat.

We briefly discussed what we could do to combat this pesky parking lot issue. I had the idea to create an actual parking lot that was off to the side – about six feet away from where the team stands up – in the hope that this would clear up the congestion. I used blue painters tape to create a small 6’ x 3’ area where individuals can now literally “take it to the parking lot.”

The first day after construction of the parking lot was complete, it was being used for discussion and the engineer sat comfortably in his seat.

Experimenting with Daily Retrospectives


I really enjoy experimentation at work, and I get a lot of value out of it. I think it’s a great way to unleash creativity, try out new ideas, continuously improve, have fun, and see what works and what doesn’t work.

One team that I coach had been playing around for weeks with the idea of doing a daily retrospective. The team is small—only two or three developers—and works in one-week sprints, so things move quickly. It’s also a research and development team, so being creative and thinking outside the box is important—these values are even stated in our team working agreements.

In an attempt to mix things up a bit, we decided to try daily retrospectives. Here’s how the experiment went.

Iteration 1: For one week, at four p.m. each day, we huddled in our team pod and discussed for about five minutes what went well and what could be improved from that day. This was beneficial because the day was still fresh in our minds. Sometimes it can be hard to remember what happened four, five, or ten days ago, so having a quick touchpoint each day is helpful.

After our discussion, if there was anything relevant to focus on for the next day, we would capture an action item or two. We would write the actions on sticky notes and put them on the team’s physical whiteboard in order to make them visible and make sure the team remembered to work on implementing them.

Iteration 2: After the first iteration completed, we decided that discussing our thoughts out loud put people on the spot and was not a great option for quiet team members. So this week—again at four p.m. each day—we huddled in our team pod, but this time we had each person write one idea per sticky note about what went well and what could be improved, and then they dropped their notes into a box. After each person had placed their sticky notes into the box, the retro was over (again, about five minutes).

For the most part, there were no discussions, other than someone asking, “What did we do today …?” Questions like that led to some chuckling, but then team members recapped what they had done, and it helped the team remember the day and come up with improvements. At the end of the week, we gathered in a conference room to open the box, and there was a lot of excitement and anticipation, kind of like opening a gift. No one was quite sure what to expect, but everyone was eager to find out.

We grouped the sticky notes on the wall to identify themes and patterns, then discussed them and captured some action items. This retro was fun and full of energy, and the team really liked it.

Iteration 3: This iteration was very similar to the second iteration, except I had upgraded from a cardboard box to a glass jar (per a team member request), and the team used different colored sticky notes for each day of the week (pink for Monday, orange for Tuesday, blue for Wednesday, etc.). When Friday rolled around, we met in a conference room to discuss the thoughts from the last five days.

However, this time when we opened the jar, we created a timeline and grouped the sticky notes based on day. We put the “plus” sticky notes (what went well) above the line and the “delta” sticky notes (what could be improved) below the line, and we grouped similar sticky notes together but all still broken out by day. At this point, we walked the timeline, discussing and capturing action items. The team liked this third iteration even more than the second.

Iteration 4: The team liked the third iteration so much that the fourth iteration was just about the same. The only difference was that one developer ranked each day on a scale of one to five stars, with five being the best, by drawing the number of stars on the sticky note from the corresponding day. It was interesting to see how his star rankings correlated with the amount of overall team pluses and deltas for each day.

In addition, because this particular developer is quiet, I asked him to walk the timeline and facilitate the retrospective. One of his goals is to improve his communication skills, so this gave him an opportunity to work on that. He did a great job, and it was nice to see him step out of his comfort zone.

Overall, it was very rewarding to see an idea quickly go through multiple iterations based on immediate user feedback. When we started our daily retrospective experiment, we really had no idea what was going to happen, and that was fine. What we ended up with by the last iteration was a retrospective format that easily captured thoughts in the moment and led to rich discussions and solid action items. It also enabled team members to grow their skills and demonstrated the value in starting small and iterating. Finally, it generated excitement and engagement, even leading to more experimentation and other benefits for the team.

For now, the team is happy with where they landed and they want to continue our daily retrospective style, but I’m sure that before too long, we’ll be trying something new again.

What experiments have you tried lately? What experiments would you like to try out?

This article was published at AgileConnection.com on 1/24/2018.

Agile Experimentation

I am a big proponent of experimentation and find it particularly useful within the Agile space. When teams are working in short time boxes, a quick experiment could add a lot of value. On the downside, if it doesn’t add value, the team can choose to end the experiment and hopefully they have learned something. With an eye toward continuous improvement, perhaps the team wants to try another.

Below are a couple of experiments that teams I’ve been coaching have tried.

Experiment #1

During a retrospective, I brought up the topic of communication. How was communication within the team? Did they think it was strong? Were they all on the same page and did they know what each other was doing? Most people said it was very strong. One person said that they knew what everyone was doing and another said they would like to know what everyone was doing but they weren’t quite there yet.

I took this opportunity to suggest a communication experiment. How would the team like to give their daily scrum update for another person on the team? For various reasons, everyone thought it would be a fun experiment, so we decided to try it for a week.

The exercise started out pretty well, actually. Around day #2, things started to become a bit more challenging and by the end of the week, the team was ready to end the experiment. The team realized that although they had good communication, there was still room for improvement.

Experiment #2

Another team had recently been broken up and was reforming. They were clearly in the “storming” phase and were having problems with their throughput. In a retrospective, we focused solely on what could be done to increase throughput and start seeing work flow across the board. A member of the team had the idea to start using a daily team goal.

The plan would be that during the daily scrum, the team would identify the top priority for the day, how much of that the team could finish and who would help get it done. The plan is similar to the typical daily scrum, but much more focused on the team rather than the individuals.

The daily team goal helped the team focus, increased their collaboration and led to a lot of swarming. The experiment received positive reviews in and out of the team and is still being used today.

I viewed both of these experiments as positive. Even though they had differing levels of success, it felt good to try something new and I believe that the teams learned something from both.

What kind of experiments have you tried?