Software Development Team Standards - Meetings
The last post in my series on software development team standards focuses on meetings. The cause of, and solution to, all life’s problems, its very easy for meetings to get too far one way or the other on the spectrum of managability. On one side, too many meetings are often a waste of resources, while on the other not having key stakeholders present in meetings can leave large gaps in knowledge and functionality that will impact the quality of your software product. Here’s a few things to look out for.
I write all this with a huge caveat - just because your team doesn’t score highly in one of these categories, doesn’t mean your team is bad! If anything it might give you some ideas and goals to strive for to address some of the pain points and issues you may be experiencing as a group.
This ended up being a huge post. I’m going to break it up into a few separate articles:
Meetings
Meetings are very much their own beasts in that each company seems to have their own unique approach to who attends, what’s discussed, how it is discussed, and what outcomes are produced from each type of meeting. That said, there are a few good guidelines to follow here:
- Non-Meeting Focus Time. How many 2+ hour blocks of time do developers get in a day? As discussed above, context switching is expensive, so ensuring it happens as little as possible will allow your developers to be as productive as they can be.
- Agendas - do your meetings have them? Not only is it a clear way to stay on track, it also communicates information before the meeting so that your coworkers can make an educated decision on whether it’s worth their time to attend.
- Action Items - as a rule of thumb, if your meeting doesn’t end with one or more action items, it likely wasn’t an effective meeting. There’s exceptions to every rule of course, but coming out of a structured, scheduled conversation with other employees should likely result in some sort of forward momentum, otherwise it was either an information sharing session (which could’ve been communicated in a more cost-effective way), or it wasn’t an effective meeting.
- Notes - if someone can’t make a meeting, is there an easy way for them to catch what was discussed and any action items that resulted from the meeting? Or better yet, for those who didn’t need to be in the meeting but are affected by its outcome, do they have access to a summary? Meeting notes should be linked to the stories that the meeting affected where applicable, so that they can be referred to later as needed.
- Clear Decision Making Roles - This might be one of the biggest overlooked areas in my experience. Having a clear delineation of who needs to be involved in what decisions can prevent a lot of friction and wasted effort during the development process. Without this, I’ve experienced teams who have senior developers acting like product owners, questioning the validity of business requirements half way through the sprint they were to be implemented. Not having a clear definition of who makes what decision can cost precious time as others are pulled in to justify past agreements and compromises that had already been hashed out. Without a clear definition of responsibilities, you end up with one of two types employees; ones who are disengaged from the process because their opportunity for contribution isn’t clearly defined, or ones that are over-involved in the process, adding overhead and complication to each individual step because it’s not clear where their responsibilities begin and end.
- Avoiding Meetings Where Possible - Of course, some meetings can’t be avoided. Most of the meetings around sprint processes, for example - the daily standups, the retrospective, the sprint planning and estimation - require as much of the team as possible to be present. It’s important that those meetings are well structured so they can be run efficiently and everyone can get value out of them. There are other meetings, however, where you don’t need to have the entire team in a room. Discovery sessions where feature requests are flushed out, refinement meetings where the success criteria is defined, discussions about particular feature implementations, can often be trimmed down to the decision makers and stakeholders, and often don’t require every single team member to be present. While it can be said that it’s important to have developers involved in the process as early as possible, I can guarantee from personal experience that those same developers are often not paying attention. And to a further point, I’ve seen teams use the excuse of having a meeting to avoid or offset a lack of details captured in story tickets. As mentioned before, a story ticket should have enough information on it by the time it comes to implementation that anyone on the team could work on it - regardless of whether they attended (or paid attention to!) any prerequisite meetings.
- Active Participation In Meetings - This is a metric that a lot of teams don’t bother tracking, or at least noticing past a superficial level. Almost every team I’ve work with and for have had one or two primary players leading the meetings, generally people who are more confident or outgoing, leaving the rest of the attendees nodding their heads in agreement (at best) or outright not paying attention (at worst). There are several different approaches you can take to encourage more participation, including things like planning poker (where estimate input is required and outliers are given the floor to explain their perspectives), rotating hosts, and just good old moderation techniques to ensure everyone is prompted and has had a chance to contribute.