Saturday, March 24, 2018

No More Standups

When I was first promoted to team lead, I had no idea what I was doing. I had worked within the team for a couple years so I knew how things were run, but I had zero management/lead experience. Although at the time I was really nervous about doing things the "right way", I look back now and realize what a wonderful advantage it was for me. Because I was so inexperienced, I didn't have as many prior assumptions and that led me to question everything.

Agile is still the main software methodology used today by software development shops. Its a way of building software that promotes efficient iteration and collaboration. Although there are different variants of agile, one of the core rituals that they do is the daily stand-up. The daily stand-up where the team forms a circle (preferably standing up because the stand-up is meant to be short) and each member talks about 3 things: what they did since the last stand-up, what they are doing, and any blockers. 

Although this stand-up is considered sacred, since I was new, I questioned it anyway. I was determined to get rid of bad processes that didn't help the team. Some of the research I found opposing stand-ups were:

1.  "manager vs. maker time": makers need chunks of time to do work and cannot work in short spurts so its best not to schedule a meeting in the middle of the day. Although the standup was in the morning, the engineers would be in there before that time and there is a worry that the meeting would prevent them from jumping right into a heavy-concentration project when a standup would cut that short.

2. Peopleware: this book is one of my favorite books on technical leadership and it has an excerpt that if people are going around the circle and only interacting with one central figure (me) then it is not for communicating with the rest of the team but more of a status update for the manager. The more insecure the leader the more they want status updates, and some really poor leaders will do multiple "standups" a day to make sure their team is getting things done.

With this hypothesis and plus the fact that the team didn't always seem enthused to be at the morning standup, I decided to cancel it. Yes. I canceled the holy Agile declared necessary standup. I had explained to the team what the hypothesis was and that if I needed a status updated I would just check our Scrum board. I'd assume things were under control if no one said anything.

After the sprint was over, during the team retrospective, we attributed some of our slip-ups to the missing morning standup meeting. The QA members of our team (we had dedicated QA) requested bringing the morning standup back. The developers on the team agreed. We needed it to explain some nuanced information. I still thought there were other ways to work besides having the standup but I stuck with the team decision. I actually think that this was a result specific to the types of personalities on the team. Other teams may not have the same results.

I was happy that I ran into an actual problem that our standup was solving and not just taking the word of the current popular methodology. Looking back, I don't see this as a failure of changing a process but rather a good exploration and lesson learned. I implore myself and others to question everything and not just assume things are needed. Try to continually improve and get better. Sometimes that will be by addition but other times you might grow by putting your current processes to the test.