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.

Iterative Retrospective Experimentation

I really enjoy and get a lot of value out of experimentation at work. I think it’s a great way to unleash creativity, try new ideas, continuously improve, have fun, see what works/doesn’t work, etc. One team that I coach has been experimenting and iterating on a retro idea for weeks. This team is small (2-3 devs) and works in one week sprints, so things move quickly. I had the idea to try daily retros. Here is how the iterating went…

Iteration 1: At 4pm each day, we huddled in our team pod and quickly (~5 mins) discussed what went well and what could be improved. This was beneficial because the day was still fresh in memory. Sometimes it can be hard to remember what happened 4, 5 or 10 days ago. We discussed and captured a couple of action items.

Iteration 2: At 4pm each day, we huddled in our team pod and each person wrote on sticky notes – thoughts about what went well and what could be improved – and dropped the notes into a box. After each person had dumped their thoughts into the box, the retro was over (again, ~5 mins). At the end of the week, we gathered to open the box, and there was a lot of excitement and anticipation – kind of like opening a gift. We all helped group the stickies on the wall, then discussed them and captured some actions items. This retro was fun and full of energy. 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 we used different colored stickies for each day (red for Monday, orange for Tuesday, etc). Then, on Friday, when we opened the box, we created a timeline and grouped the stickies based on day and plus/delta/topic. At this point, we would walk the timeline, discuss and take actions. The team liked this method even more than the last.

Iteration 4: The team liked the third iteration so much, that the fourth iteration was just about the same. The only main difference was that one developer ranked each day (1 – 5 stars), which was interesting to see his ranking with the plus/deltas from the jar. In addition, this developer is quiet, so I asked him to walk the timeline, which is in line with one of his goals of improving his communication skills.

Overall, it was really nice to see an idea quickly go through multiple iterations. It generated excitement and engagement, and even led to more experimentation and other benefits to the team. For now, the team is happy with where we landed and they want to continue this retro style, but I’m sure that before too long, we’ll be trying something new…

What experiments have you tried lately? If none, then what experiments would you like to try out?

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.

5 Things Learned From Steve Jobs

Last week, I (virtually) attended the Lean Startup Conference and heard Guy Kawasaki – former Chief Evangelist at Apple – speak about 10 things he learned from Steve Jobs. Below are the 5 that caught my interest, along with some of my thoughts…

1. Customers can’t tell you what they need (you need to help them figure it out)

I think it is important to keep in mind that building the right feature takes collaboration and communication. This is similar to how a Product Owner presents a user story to the dev team and then there is a discussion to clarify points, add acceptance criteria or discuss why another approach could be a better idea.

2. Changing your mind is a sign of intelligence

This is very much in line with Agile thinking, which is why we work iteratively and incrementally and why continuous improvement through inspecting and adapting is so important.

3. Engineers are artists – treat them like artists

Just like an artist, engineers need space to be creative and innovative (no micro-managing). They also need time to work on their craft, for example, time to refactor so they are not introducing technical debt.

4. Innovators ignore naysayers

There are many reasons why people will say something can not be done. Perhaps they don’t understand the vision, maybe a particular idea threatens them or they don’t like thinking outside the box.

5. Some things need to be believed to be seen

Guy explained this as the idea of sometimes people won’t take the time to see something until they’ve been convinced of the idea. So, really understanding the benefits of a feature, being persuasive and convincing people of the idea many times is the first step.

Please let me know what you think.

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?

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.

Five Ways Leaders Can Help Agile Succeed

Leadership undoubtedly plays a large role in helping Agile succeed. Here are five ways that leaders can help enable the success of an Agile program.

Create the right kind of environment

Creating an environment where people can take risks, experiment, fail and learn is extremely important if teams are going to continuously improve. An environment where people are afraid to make mistakes is an environment that is bound to fail. Leaders should help create a workplace that is fun, but where people are motivated and accountable.

Remove organizational impediments

It is critical that leaders help remove organizational impediments so that teams are not slowed down and can be as high performing as possible. This starts with identifying impediments, whether it’s establishing a communication channel to elicit feedback from teams or having an Agile coach provide insight. Next is taking action to remove the impediments. There’s a cumbersome change request process in place that is slowing down the delivery of products? Leaders need to find a way to change or eliminate that process. Teams are spread out on three different floors? How can leaders relocate the team so they all sit within earshot of each other?

Be transparent

One important aspect of Agile is transparency. From knowing what backlog items are being worked on to having a clear definition of done, transparency adds clarity and trust. Leadership should lead by example by being transparent and therefore providing clarity to their teams and building trust within the organization. Even if being transparent reveals some dysfunction, that’s good because now that dysfunction can be addressed.

Communicate the vision

Even self-organizing teams that are working hard to finish their sprint goals need to come up for air and make sure they are headed in the right direction. Leadership should be communicating the overall organizational vision so that the team can understand how they fit into that view. Another important part of the communication loop is listening and welcoming questions and feedback.

Trust the team and get out of the way

Teams will perform better when they are not micromanaged and told how to do their work. They are on the team because they are good at what they do and the team is using Agile so they can perform at higher level – so leaders need to get out of the way and allow teams to unlock their true potential. You will be surprised what your teams can do if you just give them the tools to succeed.

Being Flexible With Agile

After being involved with many Agile teams across a wide range of organizations – one thing is certain: each group will have their own style and flavor. No organization – whether a startup or Fortune 50 company – or team – distributed or collocated – will be the same. And in my opinion, that is a positive thing that adds value – not only to that specific situation, but to the Agile community as a whole.

The Scrum Guide, Agile Manifesto and other bodies of knowledge provide guidelines to follow, but flexibility is necessary in order to meet the needs of a particular project or client. Let’s face it, if teams aren’t flexible and don’t adapt to a given situation, there are times when nothing would get done. And typically, the goal is to produce working software, not to be in compliance with the Scrum Guide.

I have met those who are a militant about following the Scrum Guide to a T and any deviation is perceived as an act of war. Typically, I have found that sticklers are new to Agile – in the Shu phase of Shu-ha-ri. I will admit that when I began learning and applying Agile, I tried very hard to stick to the “rules”. However, I learned a while ago – after being exposed to various teams, organizations, levels of Agile experience, clients and situations – that being flexible with the application of Agile methodologies is important and probably a necessity.

The more experiments run and ideas tested only add to the amount of knowledge circulating throughout the web, conferences, Meetup groups and impromptu conversations. One of the great parts about Agile is the agility that it provides – the risks taken, the lessons learned, the nonconformity.

So how about you – do you strictly adhere to the Scrum Guide or do you tailor your approach to the specific situation? What are the pros and cons?

How to Make an Agile Transformation Stick

Previously, I wrote about top-down and bottom-up Agile transformations. After the organization has started their transformation, it is important to make sure that the teams and organization are not slipping back into their old habits. Especially if Agile is new, it is easy to regress. It’s critical to stick with it so the teams and organization can get the most out of the transformation. Below are three focus areas that I believe are important to help a transformation gain steam and then begin to make lasting change.

Those who are not familiar with Agile need to be educated, and those who are familiar with Agile should continue their education. Identify areas within the organization that could be improved and explain how Agile methodologies can make a positive impact. Create an Agile champions team and encourage Agile ambassadors to spread the word or hold lunch and learns. Invite people to attend the daily scrum and look at the burndown chart so they start to get an idea of how the teams operate. Engage others and encourage their teams to become Agile.

An organization is not going to transform over night. Or in a week. Or in a month. Set expectations that the process will take time, but remind people that the team is completing work and inspecting and adapting regularly, so they will be able to provide feedback and see continuous improvement. Let people know that Agile brings a level of transparency that will help make challenges visible early on. Bringing Agile into an organization can be a culture change, so be patient.

From an executive level, let the team know that you are behind them and support what they are doing. That is important and can make a difference by letting the team feel comfortable and confident to try new things, learn and get better. From a team level, be willing to engage with management and explain what you are doing. Justify why pair programming is helpful and not a waste of time. Explain the importance of having the team sit in the same room. Also, don’t undervalue the importance of Agile coaches. They help get teams up and running, but also make sure that teams are continually improving and performing at a high level – not just flatlining and being content.

Education, patience and support. Do you have any other ideas on how to make an Agile transformation stick?