Over a million developers have joined DZone.

The Precious Feature Design Meetings

Discussion about the point of meetings aside, there is one type of meetings that I love. It has many names: design review, design overview, feature design.

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

As we know, meetings is where work goes to die. Discussion about the point of meetings aside, there is one type of meetings that I love. It has many names, depending on who you ask – design review, design overview, feature design. And I see it as the most important meeting in software engineering.

What is it? Let’s start with a little background. You are probably “doing agile”, so you have user stories. They are already groomed and sized (based partly on some known details and partly on intuition), and you have to start working on one of them. (Below I will use the auxiliary verb “should”, because this is part description, part recommendation.)

But before diving into coding, you, together with another team member, should take a step back and discuss how exactly would the implementation look like. What programming and design approaches should be taken in order to complete the story. These include discussing an API you’ll expose, the interactions between components, or even a deployment procedure. It may involve using UML on a whiteboard. Don’t waste too much time on the details or discussing “which way is slightly better than the other”, as you can refactor that later.

After that you hold a meeting where you present the result of your analysis to the team. The team may have questions, or suggestions that you didn’t think about, so the meeting itself is both informative and productive.

This is not applicable to all stories – some are absolutely obvious, so having a meeting would be a waste of time. But whenever there’s some specific design decision to be made, or even a broader question “how do we do that?” to be answered, these short meetings are golden. Not only because you take better decisions, but also because everyone on the team is informed about the decision and more importantly – about the reasons for that decision. So when another team member has to work on the same part of the code base in three weeks, he’ll have at least part of the picture still in his head.

I would recommend having such meetings (limiting them to 20 minutes), for the sake of having better design and a more informed team. And they are not actually “full-featured” meetings – they don’t need to be on the calendar a few days prior, and depending on the size of the team, they can be done even while sitting at your desks (or via skype), almost as a casual conversation.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.

agile,feature design,team collaboration

Published at DZone with permission of Bozhidar Bozhanov, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}