We didn’t complete our sprint, again…
As an engineering manager, I often discover leftover tasks at the end of a sprint. This “incompletion” typically had triggered panic early on in my manager career. In a metrics-driven performance culture, my sense of panic seemed justified, every time.
Today when facing the same situation, my brain doesn’t produce nearly the same amount of adrenaline anymore, not even close. I still deeply care about the team’s productivity and performance, but my frontal cortex is occupied by curiosity instead of panic. “How do you handle an incomplete sprint today?” you may ask. I can walk you through what took place on Nov. 22nd, 2019. All real names are replaced with fictitious ones.
Our combined sprint retrospective and planning meeting started on time at 11 am. Baylor, the product manager, myself, along with 4 engineers (Carl, Yuri, Peter, and Gilbert) sat in a conference room with our eyes gazing at our laptop screens. “Alright guys, let’s take a look at our sprint board,” Baylor said as he was projecting his screen with the sprint board onto the big screen TV.
I noticed two things immediately: Baylor’s eyebrows had formed a tight knot, and everyone on the team has at least one unfinished task left. “Hmm, it looks like we didn’t quite finish our sprint. Let’s dive in and discuss what happened,” Baylor proceeded to discuss with each engineer on the team on the status and remaining estimate of every unfinished task.
As the discussions went on, the engineers’ responses to “what’s the status of this task?” and “how much is left on the task?” became increasingly defensive. Responses followed familiar themes: “I am almost done with this,” “I realized it was more complicated than I thought midway through working on it,” and the classic “it should be done in the next sprint.” My curiosity compelled me to create an impromptu engineer-only meeting towards the end of the day, with a description of “sprint performance discussion”.
It was business as usual for me from noon to 4 pm: attending other scheduled planning meetings, checking in with our recruiting team on the health of the pipeline, one-on-one meetings with fellow engineering managers, and typing replies to the endless stream of Slack messages.
When the clock hit 1600 hours, the engineers came to my desk and asked if there was a conference room booked for the meeting. I said, “no, all the rooms were booked.” I then suggested that the team meet in the common area at the corner of the office, i.e. out in the open. Everyone okayed the meeting venue, but I did sense a slight awkwardness.
We sat down in a circle. Everyone looked serious — this is not normal for this fun group of people. So I first smiled, then looked at everyone in the eyes and said, “It was great that we talked about the leftover tasks with Baylor earlier. But I didn’t think we were communicating the substance of what caused the delays.” I continued, “I don’t know all the problems the team faced in the last sprint. I think we should openly talk about all the distractions, blockers, or anything else that got in the way. I would love to know what I can do to help the team move faster.” The team jumped right in immediately after I finished my sentence.
Gilbert: Three main factors affected my productivity. One, I was on call last week. The unexpected out of memory error on the database was a really mysterious and complex issue. It took me three days and lots of help from the rest of the team to finally resolve it. Two, I tried to break down the refactor task into many small PRs with sequential dependencies. Every time I need to make a change to a PR, I had to make appropriate changes to all the downstream PRs. This took a lot of time. Three, when I was working through the refactor, I found myself going down one path but would discover a better approach halfway through. This happened 3 times.
Yuri: Yeah, the out of memory error definitely took quite a bit of time out of my week. Aside from that, I was dealing with a lot of questions from our stakeholders on NetSuite. Our NetSuite integration issues keep happening and they have been asking me a lot of questions directly on Slack. It was very distracting.
Me: So could you have directed the questions to Gilbert who was on call?
Yuri: No, I am the only one on the team who knows how our NetSuite integration works.
Peter: I had a hard time focusing during the last sprint. I had a lot of meetings and interviews. I had a few 1-hour chunks of time in between meetings, which was not enough for me to do any meaningful focus work.
Me: how many interviews did you do?
Peter: I did 12 interviews, totaling 12 hours.
Carl: I also spent 6 hours on interviews in the last sprint. Also, I am new to the project. It took me some time to read and understand the code for every task. I have also had to ask others for help.
Me: It seems like our active participation in interviews came at the cost of our product work. How have you filled our your interview availability time block form?
Pablo: I indicated that I would be available every day during the week.
Carl: Yeah, me too. I thought the form was asking when I could be available. I didn’t realize that I would actually be scheduled for interviews every day.
At this moment, I was satisfied with all the input from the team. This team has been a high-performing team, so I wanted to check if there were other issues. I asked, “Thanks for the open discussion, I can certainly help with a number of the issues. But assuming we have no external distractions and you all have large chunks of the day to focus, is there anything else that could get in the way of our execution?” Everyone shook their heads and said “no” almost the same time.
“Okay,” I said, “It’s great that we can discuss the issues as a team. These are very fixable problems. Let’s address these issues together. I will be creating action items and assigning owners to each.” Everyone seemed hopeful at the end of the meeting.
I started creating tasks for the team as soon as the rest of the team left the common area:
Scale the NetSuite integration knowledge. Start building a support issue runbook that documents the symptoms, root cause, troubleshooting steps, and resolution. This is assigned to Yuri.
Manage your interview time blocks. Fill out your interview availability blocks again and make yourself available only for the days you are prepared to be disrupted. This is assigned to everyone on the team.
Discuss a strategy to effectively manage code branches on a complicated refactor. This is an open-ended task for the team to create a process to balance between minimizing the size of PRs and minimizing dependencies. This is assigned to Peter to kick off the discussion.
The stories unfolded during the team discussion revealed the true causes, but my intentional effort created a safe environment for the team to open up.
My curiosity prepared me to listen to the team with a genuine intent to find problems.
By intentionally meeting with the team in the open common area, I signaled to the team that this was an honest, open discussion focused on discovery and solutions.
The team is held accountable by owning the action items to address the problems.
How did your most recent sprint retrospective meeting go? What were some interesting stories your team shared?
