You need a partner who takes the time to understand what success means to you. That’s DockYard. Book a free consult today to learn more.
Stand-up meetings. Product Owners and Scrum Masters pretend to love them, engineers make fun of them, and management loves to tout them as proof that they “do Agile.” Why do we do them? Are we all just wasting our time?
When focused correctly, a stand-up meeting can multiply the capacity of the participating engineers and double team velocity. Let’s take a look at some of the tools we have used to make stand-up meetings actually useful for the people involved, and how using the Parking Lot can make your stand-up meetings much more effective.
Drawing the Lines
First things first, we need to be on the same page about the purpose of stand-up as a concept. Around the agile development world, you will see this meeting referred to as a “Daily Scrum,” a “daily huddle,” or “stand-up”. All of them describe the same thing. Stand-up is probably the most well known, so we will use that in this article.
Let’s take a look at how the Scrum Guide defines the stand-up meeting (emphasis mine).
“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.”
What is this daily meeting? It consists of the developers inspecting progress towards the goal and adapting the contents of the sprint to accomplish that goal. The team checks on itself, asking what it needs, what is in the way, and what they can adjust today in order to reach their short term goals effectively.
“The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.”
Who does this meeting exist for? Often, management will use this meeting to keep tabs on who is doing what and to see if their timelines are accurate. While these might be helpful outcomes of a daily stand-up, they are not the purpose of the meeting. A stand-up is for the developers, meaning anything that is not helpful for them to achieve the purpose of the meeting has to take the back seat.
Sometimes, you will hear a facilitator opening the meeting with an ask for everyone’s “updates.” While innocuous at first, this subtly pushes the culture away from the developers and toward existing for management updates. While stand-up does normally have some sort of facilitator, make sure they keep the meeting for and by the developers.
“The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.”
What does this meeting even look like? Many people have their format of choice. Whether it is the classic “What did you do yesterday, what are you doing today, and is there anything in the way?”; going around the room asking about progress towards the goal; or simply asking for only blockers, the structure of the meeting can look very different for different teams. Pretty much anything goes so long as it accomplishes the purpose of inspecting progress towards the goal and adapting the necessary work to reflect what is left.
So if the meeting isn’t for the “non-developers” and can look different for every team, what is the right venue to have team announcements, spontaneous refinements, architectural discussions, and so on?
Let’s Hang Out in the Parking Lot
The Parking Lot describes a laundry list of extra items tagged on at the end of stand-up. While no one is quite sure who to credit for it, the Parking Lot (or the Car Park for our Australian friends) has been dubbed the “unofficial Scrum ceremony,” practiced by many teams of all sizes. This normally looks like an extra 15 minutes or so tagged on the end of a stand-up to fill out the half hour.
While this can easily become a catchall for everything else and recreate the same problems people have with stand-up, a well-curated Parking Lot can help the team work even faster and with better collaboration. At DockYard, we accomplish this through overcommunication and transparency.
First, if we know what we need to talk about in advance, we send out the itinerary before the meeting. In Slack, we will send out a couple notes on what additional items we need to talk about, and anyone who has something to add can tag it in the thread. This helps to both give people the opportunity to come prepared to discuss something they may not be as fresh on, and to help identify what is worth talking about and what could be addressed without a wider discussion.
Second, we make sure to keep stand-ups timeboxed within the 15 minute window. The meeting is efficient, direct, and utilitarian. One at a time, we each discuss progress toward the goal, escalate anything stopping us from hitting that goal, and track any unexpected items we need to do in order to hit the goal. Anything that comes up that needs further discussion is then “parked” in the Parking Lot for later.
Third, we kick people out. Don’t get me wrong, the meeting is open-door. We just don’t want to waste anyone’s time. So when regular stand-up itineraries are done, we tell people to leave unless they have something to contribute to the things we have on the docket to discuss.
Last, but very tied to the third point, we send out a summary of what we discussed. This way we get around the possibility of people feeling FOMO from requirement discussions and hold ourselves accountable to making meaningful decisions quickly. Any process, architecture, or design discussions are written down for anyone who didn’t stick around.
All the questions on progress, delivery dates, and new business requirements are important and will have their time and place — after the current day’s issues are sorted out. Oftentimes, that information can be gleaned from the developer’s conversation around the sprint goal, resolving the Parking Lot agenda item before you even get there!
Learning to Drive
Getting stand-up right is vital for the team to succeed and work together towards shared goals. It takes time, practice, and mistakes to get there! Across many engagements, we have finessed this process in all sorts of team structures. A thriving team of engineers is the essential foundation of a quality product. Start by getting the little things right, and the rest follows!
