Dev Huddle: An agile ceremony for devs

This article was also written in portuguese here: http://bit.ly/dev-huddle

I've been on the same squad at the company I work, Gupy, for a year and a half. One thing that my team struggled a lot with was the effectiveness of our sprint planning.

It was more than often that our planning went over 3 hours, we spent a lot of time switching context from business value to implementation details to complexity estimation. Just like "code smells", we could tell in our meetings that something smelled bad: often when we diverged a lot in estimating and someone would give their rationale, it would be "Because I don't know much about front-end/back-end" or "I never dealt with that part of the code, but I heard it's messy".

Those smells were justified with some of our metrics. We didn't have a stable lead time, and even though we refined our path to production, sometimes we would have crazy outliers in the in development phase. Along with that, we had a low predictability in delivering our sprints. All of that with what we call Developer unhappiness, because often we were to find the task to be much harder than what we anticipated and the anxiety would settle in.

So, after a few retrospectives with the same "to improve" card, we decided to experiment a new ceremony to improve communication between developers.

Huddling

After mapping out the problems we wanted to improve, such as long plannings and miscalculated tasks, we began creating a ceremony called Dev Huddle.

According to wikipedia:

"In sport, a huddle is an action of a team gathering together, usually in a tight circle, to strategize, motivate or celebrate."

The idea behind the huddle is that we are going to take a look at the upcoming sprint cards and discuss one by one to strategize: foresee any problems, talk about implementation details, share knowledge and commit to the scout's rule.

Just like a retrospective, we have directives: We assume nothing and We all should feel comfortable with the decision made. This is important to make sure we are strategizing through evidences and we are all collaborating with our mission.

Let's play roles

To do a huddle, we gather in a room just a few days before the next sprint planning for an hour and we get some volunteers in a few roles: Sherlock, Watson and the Time Police.

Sherlock is one team member that will share screen with the group and go through the code, product or documentation to help answer questions.

Watson is another team member that will keep notes for all the decision made, populating the task card and making sure nothing goes undocumented.

Time Police is other team member that makes sure we keep each card discussion to a timebox (normally 10 minutes) and begin facilitating, by asking questions to start the discussion.

It is important that everyone on the team participates, coming up with ideas, questioning and sharing knowledge.

How it works

“Never trust to general impressions, my boy, but concentrate yourself upon details.”

To get started, the time police begins by reading the card (that should be made available before the huddle). From there, some questions begin to pop:

• Is everyone comfortable with the definition of done?
• Can we break down this task in smaller ones?
• What are the steps to get it done?
• Does this task involves saving data in DB? If so, what's the strategy?
• Is it easy to deal with the business logic?
• Do we have tests for this piece of software? Should we add more? What's the strategy?
• Which endpoints should we use?
• Do we have an UI sketched? How are we dealing with new components?
• Do we have any TODO on the way? Can we tackle it?
• Do we need to refactor? If so, what would be the length of this refactoring?
• How can we monitor this task? What metrics are we going to keep track of?

These are some of the questions we are discussing every huddle, but the general idea is to ask questions to bring common knowledge. Since no one is assuming anything, we can make "silly" questions and have valuable discussions that otherwise wouldn't exist.

And what do we get out of this?

We began running huddles in our team about 6 months ago. The first positive result we got was that our plannings went down to 30 minutes to an hour max. This is huge, not only because plannings are shorter and more efficient, but we saved the Design and Product team hours of their work by not making them listen to hours of technical discussion.

One thing that caused our Developer Happiness to increase was that we got to agree on a refactor mission for a lot of our tasks. Before the huddle, it was unclear when and how to deal with tech debt, and as a startup in exponential growth, it was hard to focus on the debt. Now we deal with it differently and as an essential as long as we deliver our sprint mission.

We also began noticing that our estimates weren't THAT different, mostly because we began breaking down knowledge silos and creating a common understanding of our tasks. We still differ in estimating and that is totally fine, because we understand that estimates are a probability, not a commitment.

To sum it up, after having great results, we began sharing with other squads at Gupy. That's when it became clear to me: you can change the questions, the roles and the time spent doing a huddle. As long as you create an agile environment to experiment, have a short feedback loop and enhance communication, you're up to something great.