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.

Continuous Improvement Board

Earlier this year – after a large, stressful release – a group of Agile Coaches facilitated a retrospective involving people from over a dozen dev teams. In order to address the retro takeaways and make the progress visible, a Continuous Improvement Board was created.

The goal of the Continuous Improvement Board was to provide a forum for people to promote and champion ideas to bring positive change to the organization. We wanted to empower people who had identified areas of improvement so they could make their ideas visible and find others who were interested in solving a problem or moving an idea forward.

The Continuous Improvement Board is in a centrally located area that receives a lot of foot traffic. Initially, people just jotted down ideas and added them to the board. After some time, we adjusted the process so that people needed to write user stories for the ideas. We thought this would encourage people to give their ideas more thought and not just throw any random idea on the board in hopes that someone else would do the work for them.

Some Continuous Improvement Board examples:

  • The creation of an Engineering Handbook to document coding standards and how to be a responsible engineer, which can be used during new hire orientation
  • The creation and implementation of team health surveys to get a pulse on how the team thinks they’re doing based on various categories (which also shows interesting trends across the organization)
  • The creation of Empowerment Surveys for various groups (PO, Engineering Managers, etc) to identify what can be improved
  • Seemingly minor things such as people would like to have beef jerky added to the snack supply

Overall, the Continuous Improvement Board has been an interesting experiment that has provided opportunities for collaboration, creative thinking and learning.

How do you and your organization focus on continuous improvement?

New Agile Acronym – EFCIC

Recently, I was preparing for a couple of speaking engagements and was thinking about how to summarize what Agile means to me.

What I came up with was Empowerment, Flexibility, Communication and Collaboration, Iterating on Feedback and Continuous Improvement.

Written out as an acronym, this spells EFCIC, which kind of sounds like efficacy, which means “the power to produce a desired result; effectiveness”.

Well, that sounds like a pretty good goal and something that Agile can help with, so here is my new Agile acronym…

E mpowerment

For Agile to work well, teams and individuals must be empowered. Empowered to make decisions, empowered to estimate effort and complexity, empowered to fail and learn from mistakes, empowered to ask questions, empowered to be creative, empowered to develop their skills, etc. If teams are empowered, they are more likely to be able to face challenges that come their way.

F lexibility

Let’s face it, plans rarely go as expected, especially in software development. The ability and need to be flexible is essential. Having the mindset that things are going to change can help be prepared when the time comes… and it will. If teams are flexible, they will be able to quickly pivot and head in a different direction when necessary.

C ommunication and Collaboration

To me, communication and collaboration have a strong correlation and both are really important. Teams need to have strong internal communication so they can become high performing and external communication so they can work with other teams and identify dependencies. Collaboration – whether it’s pair programming or working with the PO to define a feature – will help teams get the most out of each other and also increase team cohesiveness. If teams communicate and collaborate, they are more likely to be on the same page, come up with better solutions and continue to improve.

I terating on Feedback

Don’t fool yourself and think that you’re going to build a product right the first time. Instead, build something small, get feedback, iterate on it, get more feedback, iterate, feedback, iterate, feedback, etc. If teams iterate on feedback, they are less likely to waste time and more likely to build the right product.

C ontinuous Improvement

Even if your team seems like they are firing on all cylinders, chances are that there are some improvements that could be made. Focusing on continuous improvement is important so teams don’t get too comfortable. Experimentation is one of the keys here because it helps people think outside the box and leads to new discoveries. Even if the experiments don’t work, at least you know what doesn’t work. If teams focus on continuous improvement, they will challenge themselves and the status quo, benefiting not only the team, but the organization as well.

Does EFCIC represent the way that you view Agile? I would love to hear your thoughts.