As one-fourth of a Growth Acceleration Partners (GAP) Agile Scrum team, Carlos Chacón is accustomed to quickly tackling complex software challenges and software process consulting. Yet despite daily standups as part of the sprints, Chacón and his team continued to find design flaws.
To combat this trend Chacón designed a simple yet effective strategy to reduce mistakes, increase developers’ project ownership, and improve employee morale.
Called “Agile After Parties,” these daily meetings empower developers to stay on the same page for maintainable code. Because they occur regularly and frequently, these get-togethers prevent last-minute discoveries during code reviews, Chacón wrote in Stand Up After Parties. Wouldn’t it be better, Chacón theorized, to find design flaws or other problems early, when developers could fix them in a timely manner?
We asked Chacón to discuss these Agile After Parties and their expected (and unexpected) benefits. Following is an edited transcript of the conversation:
GAP: What’s your role at GAP.
Carlos Chacón: I am a software developer; right now I’m part of the Ruby on Rails team.
GAP: What scenario were you facing?
Chacón: The most important thing you have to keep in mind is that when you program, basically you are putting your thoughts on the computer. Having around 30 to 40 people doing the same thing is complex because each mind is a whole world in itself. There are standards we have to follow. There are design concepts we must keep in mind when we develop.
Sometimes someone will think, ‘The solution I have is best,’ but maybe another person will think differently. Trying to get to a middle ground – while adhering to standards and agreed-upon concepts – is difficult.
There are several tools and techniques we can use to do that. The first ones come from the Agile world – things like meetings; using a versioning tool; having discussions about the coding standards we want on the project, doing research and then passing that knowledge to the team. We also do code reviews. At the end of the development, the rest of the developers look at read-in code and express their opinions.
GAP: Sounds pretty comprehensive. Why did you feel an After Party was needed?
Chacón: We were making the most out of these tools, but we were still having a problem. Sometimes a developer was developing a big feature on his own. While he was developing that feature, he was not in constant communication with the team. When he came up with a solution and sent it to the code-review process, sometimes some of the other developers would see there were serious design flaws.
The problem was there wasn’t any time left. That’s when we started thinking we’ve got to start catching these design flaws or wrong decisions much earlier, before they get to code review.
GAP: In a Scrum process, where do Agile After Parties fit in?
Chacón: We already had daily standups, but those meetings are more oriented to discussing business-specific issues with the Scrum Master. I thought, ‘why don’t we add 10 to 20 minutes to the daily standup meeting but without the Scrum Master and the daily team. As developers, we could discuss what we are doing at the moment.’
Each developer takes a turn and says, ‘this is where I am. This is what I am doing.’ After Parties include three to four people. After all, Scrum teams tend to be small so After Parties are going to be small.
Basically, the developer shares his design process with the rest of the team so we can catch any problems before it gets to code review. Each day, every developer gets feedback from the rest of the team.
GAP: Since you implemented After Parties, what results have you seen?
Chacón: From an ROI perspective, we’re evaluating and comparing metrics from the bimonthly sprints. They show that the number of points we’re managing to resolve has increased. It’s improving the team’s velocity.
From a less measurable perspective, the overall morale of the team has improved. There’s an overall sense of ownership now.
Every member of the team knows what every other member of the team is developing. It’s not something that can be measured with numbers, but it’s something that we have noticed.
The overall sensation of the development cycle has improved. Since we discuss more detail of the design and code each day, everyone knows what others are doing. When someone has to address a feature that another person developed, they know their way around.
There is less frustration and struggling. They get to spend some time on design research, software process consulting or understanding someone else’s code. Everyday work is a bit easier. Developers can focus on the important stuff. There’s a real sense of teamwork. Having this kind of flow makes developers more effective and productive.
In the end, while points we are measuring have improved, I think the overall satisfaction of the team is the biggest improvement.
For more information about software process consulting and other services offered by Growth Acceleration Services, contact us.
Comments are closed.