Stand Up After Parties

Designing software solutions is a complex matter, but what it is even more complex is keeping the whole team on the same page regarding maintainable code. Why does this happen and how do we deal with it?

We all have a different set of ideas on what the best way to write good code is, which is based on our experience, research and work ethic. Each mind is its own universe, and that is something important to keep in mind during the whole development process.

Code Reviews

A great tool to bring these groups of design ideas into a common ground are code reviews. Every design decision is shared with the rest of the team and there is an open space for discussion. Having a solid “code review culture” in your team is really nice.

After Parties’ Origin

Let me share a small story with you. In my current team, we were facing a problem: we already had a nice code review methodology set up, but something was missing. There were times when the code that was being submitted for review had design flaws and the rest of the team agreed a better solution existed. Refactors were needed but there was no time left for them.

We needed to detect these flaws before the code review… but how?

We use Scrum, so we have daily stand ups to share our status with the rest of the team. This was the perfect place. We decided that we were going to have an open space after the stand up of around 10–20 minutes to share our design decisions.

My friend Andres christened them “after parties”.

What Is An After Party?

The main difference between an after party and a regular stand up is that it is “code centric”. We only discuss code. Each developer gets their turn to show what they are doing, the design decisions they are making, most of the times, share the code they are currently working on.

The other developers give their own perspective about the discussed code, sharing things like design patterns, existing code that may help, useful APIs and so on.

An after party can be considered a blend between a stand up and a live code review.

Benefits

Why you should implement after parties in your project?

Design Flaws Decreased

The main benefit is the original reason for having after parties: design flaws. The benefits manifested early on and the number of big changes during code reviews went down.

A Sense Of Ownership

As the whole team shares feedback about each feature and bugfix made, a sense of ownership is created in each developer. They feel responsible for the entire project, not only their own stuff.

Knowledge Sharing

A great benefit when you have junior developers in your team is that seniors can help them improve their game more rapidly. All of the questions juniors may have get an immediate answer, which creates a discussion that enriches all of the involved parties. This is something that may be difficult to achieve during a code review.

Improved Feedback During Code Review

The whole team knows the context of each feature submitted for code review which allows them to give better and more informed feedback to the developer.

Conclusions

Agile team generally have their own take on how to develop projects. The after parties originated from a real need that my own team had. Having an open space to discuss code related topics is important. Maybe other agile teams can benefit from having an after party. Thanks.