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.

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?

Teamification: Agile Team Self-Selection

Earlier this year, while consulting as an Agile Coach, I was involved with an interesting experiment. The experiment asked individuals to self-select into software development teams. Team members would be allowed to choose what products they worked on and who they worked with. The event was called Teamification Day.

I had never done anything like this, so I was excited and also interested to see the process and results. A lot of effort went into preparing for the event. The Agile Practices group – which I was part of – took the lead by designing the event and communicating information.


Each work package (epic or larger) had an assigned Product Owner and dev lead. The PO and dev lead worked together to design a presentation that explained their work package. This would be used on Teamification Day to educate and recruit people to their team.

Each pair also had a board that would later be used to indicate interest in a specific work package and would eventually indicate the final roster for that team. This board contained valuable information, such as:

  • Standard constraints: The required makeup of teams (ex. 3-5 devs, 1 PO, 1 Agile Coach)
  • Team is able to deliver end-to-end solution
  • Where the team would be co-located (Chicago, for example)
  • Team information: Name, value stream and work package
  • Skills desired: Ex. One FE dev, two BE devs, UI/UX and also specific knowledge if necessary (Elastic Search, Java, Kafka, Nifi, Selenium, etc)
  • Team adjustments: After each round, teams would use this space to identify what they still needed or what they have too much of

The Agile Practices group created the boards and then had a couple of dry runs to see how it felt and what issues we thought needed to be addressed. There were a handful of issues and ideas – ranging from ‘will the areas be too chaotic with so many people and so many questions?’ to ‘do we need flags to indicate the team’s location, whether the team is fully formed or not fully formed?’. The goal of this event was to allow roughly 200 people to learn about 25 different teams, ask questions and then choose their own team – so we knew there were going to be obstacles.

Curiosity Market

On the morning of Teamification Day, there was breakfast – along with excitement and anticipation – in the ballroom. After some short messages from various leaders, the Curiosity Market was opened. The Product Owners and dev leads stood by their booths and pitched their work packages – explaining what they would be working on, why people should be interested and exactly what kind of team they were looking to form. The room sort of resembled a science fair.

Since there were so many teams, several rounds were run and the time slots were staggered – with some presenting and others taking a break – to give everyone an opportunity to get the information they desired. As is typical with many Agile events, the law of two feet was encouraged to allow people to move around and do what made the most sense to them.

Team self-selection

Following the Curiosity Market was lunch. The Agile Practices group discussed how the morning played out and went over last minute coordination details for the afternoon. We discussed that despite (what we perceived as) a successful morning, the afternoon would be more complex. Anything could happen as people started choosing teams. However, we had discussed possible scenarios and were armed with techniques to facilitate various situations.

As the self-selecting portion kicked off, some teams were formed quickly, as there were some individuals and groups who had previously discussed where they would like to be. The rule was that anyone could put their name on any team board – even if that team ended up having 15 people who wanted to be on it. After a couple of rounds, most of the teams were squared away, but there were some teams who had too much of one skill and not enough in other areas. The event facilitator asked teams to call out what they needed – for example, ‘we need two front end devs’ or ‘we are short one tester’. At that point, teams would know where the gaps existed and could go discuss and recruit people to help complete the team.

After a little more discussion and pitching from Product Owners, all the teams were formed.

Post team self-selection

Months after the teams self-selected, things seemed to be going very well. Individuals seemed happy with how things turned out and in a recent survey, the self-selection process was called out by many as a positive. There were only a handful of people who did not get one of their top choices and providing the freedom to choose your own destiny was appreciated. Of course, not everything is or was perfect – there were a couple of people who have been traded to help better align teams and when teams moved on to different work packages, the work was not the same, which was a little disappointing for some.

Another interesting idea that has been rolled out are job boards. A job board is a place where teams can advertise that they are looking for a skill and others can view the board to see what team they would like to join. There are certain constraints – for example, people need to be on a team for 3 months before moving – but people will also be allowed to switch teams if they’d like.


Overall, I am grateful to have been a part of this self-selection Teamfication experiment. By most measures that I see and hear, it was a success. It provided the freedom and autonomy for people to choose teams for themselves, which conveyed a message of trust and accountability. Self organization was center stage in this experiment and it proved, to me, that empowering individuals can be a strong force.

Agile Transformations and the Chicago Cubs

If you live in or near Chicago or have been paying attention to baseball this year, you know that the 2015 Chicago Cubs have made an amazing turnaround. I have been following the Cubs and have noticed several ways that they compare to a successful Agile transformation.

The culture has changed

The Cubs new manager, Joe Maddon, has instilled a sense of transparency, accountability, support and fun. One of the most important and difficult aspects of an Agile transformation is changing the culture. When a transformation receives top down support, it helps to motivate the teams and greatly increases the odds of success. Agile is a different way to work than waterfall, for example, and it makes some people uncomfortable because letting go of command and control isn’t easy. The team needs to be empowered to make decisions, but also know that they are held accountable. A culture that allows failure because it results in learning is important. Teams need to feel comfortable to try new approaches so they can find what works best for them.

Cross-functional teams

The Cubs have many players that are able to switch positions throughout the game. Even in the playoffs – the most important time of the year – people are playing several different positions in one game. Key players get injured and the team doesn’t skip a beat. Applied to Agile, cross-functional teams help ensure that team members are not working in silos and increases collaboration. Spreading knowledge and skills across the team helps them thrive and provides the ability to be more dynamic and responsive to change. There is less concern when someone uses PTO or gets sick because team members have the ability to play several roles.

Keep it simple

“I always talked about simplicity” and “The simpler solution is probably the better one to go with” are a couple of things that Maddon has said this season and he’s also referenced Occam’s razor (’The simplest solution is usually the correct one’). This attitude is very important for an Agile transformation because organizations and teams are trying to transition from a very detailed, let’s-get-everything-defined-up-front kind of attitude. With an Agile transformation, identifying an MVP (minimum viable product), writing small user stories that are expressed in the language of a customer and emphasizing face-to-face communication are examples of how keeping it simple helps to be successful. Building in short iterations and then inspecting and adapting help make the process more simple.

Just in time planning

When the Cubs started the season, Wrigley Field was under construction and several of their key players were not even on the team. The Cubs did not need everything  in place to start the season. They continued to build on their stadium and their team as the season went on. This is a key lesson during an Agile transformation. The notion that all requirements do not need to be detailed before the project has started can be difficult when you’re new to Agile, but a just-in-time process will keep the team focused and help avoid waste. A key aspect of Agile is learning as you go and adjusting the plan based on what you learn. Short iterations, having a few sprints worth of stories groomed and using retrospectives help teams be nimble and adjust on the fly.

Please let me know what you think, and Go Cubs.