If you work in an organization, you’ve experienced bad meetings. These soul-sucking, time-crushing meetings leave you deflated and wondering if you’ll ever be able to get anything done. Learning how to make sure that developers are only in the meetings they need to be in—and that the meetings that they’re in are productive—is a key way to maintain developer productivity.
It really doesn’t matter whether you’re using an agile software development methodology, waterfall, or a blending of the two that you call something like “Agile-Fall.” In truth, the meetings that you experience as a developer share common characteristics no matter what the methodology. Let’s look at agile meetings first.
Agile Meeting Types
Developers working in agile projects typically experience four basic kinds of meetings. The daily standup meeting is the most frequent, and therefore potentially the most time-consuming. The backlog, or estimating meeting, occurs each sprint or iteration so that developers can estimate the effort for each task and determine dependencies. Show and tell meetings occur each sprint to help demonstrate what’s working. These meetings are primarily designed for the clients, but often developers are asked to join to “show off” their features. The other meetings are “traditional” meetings, which may include organizational meetings as well as requirements-gathering meetings that developers get pulled into.
Everyone is supposed to stand up to keep the meeting short. Three questions are designed to elicit commitment and create opportunities for support. The three simple questions are:
- What did you get done?
- What will you get done?
- What is in your way?
The questions themselves are designed to elicit specific, tangible answers that should take only a minute or two for each person; but, the standup goes awry when developers ramble, because they’re not mentally ready to answer these questions. Simply coaching developers that they should be precise and crisp in their “check in” can cut a lot of time out of these meetings.
Keeping standup meetings to 15 minutes or less takes some skill, especially with larger teams, but it’s important to minimize the negative impact on developer productivity.
Backlog Estimating Meetings
Most meetings that are scheduled on a professional’s calendar are scheduled for either half an hour or an hour. This is a reasonable block of time for coming to a resolution. However, backlog estimation meetings are often scheduled for more than an hour. They’re sometimes scheduled for two hours or more. The problem with this is that these meetings tend to try to solve multiple, quasi-related needs.
The first need is the need for the product owner to prioritize the backlog to determine what should be in the next sprint. To do a final order for the sprint, it’s necessary to know how big the effort is for each of the items that are being prioritized. The second need is for the developers to provide estimates for the effort for each of those tasks. Typically, the developer estimates—or, in reality, revises the estimates—for the items that are going into the next sprint, so there’s a reasonable goal set for what should be completed.
The challenge is that the developers don’t need to know what the product owner is prioritizing. They only need to know the task so they can estimate it—and identify any dependencies for the task. The meeting can’t run as two or more separate meetings, even though there are multiple objectives.
Instead, consider a staggered invitation, where the product owner is invited for the first half hour, the developers for the middle hour for estimating and discussion, and a final half hour for just the product owner to tie up loose ends. This allows the project manager and the product owner to be specific about what they need from the developers—and allows them to be efficient with their time as well.
Even though product demonstration meetings may be scheduled for only an hour each iteration, the time adds up if you have every developer there for every feature—and the discussion is a wandering discussion about the new features and the implications. By dividing the meeting into two, half-hour chunks, with the first chunk being a straight demo of the new features and the second half as discussions of relevant questions, you can free developers who didn’t work on features that need discussion from the extra half of the meeting.
Managers experience at least a third of their meeting times as unproductive. (Bang, H., Fuglesang, S., Ovesen, M., & Eilertsen, D. E.. “Effectiveness in top management group meetings: The role of goal clarity, focused communication, and learning behavior.” Scandinavian Journal of Psychology, vol 51, 2010.) Much of the challenge with traditional meetings is that they don’t have an agenda, the space isn’t planned well, no one records the minutes—including action items and decisions—of the meeting, and no one is held accountable to their commitments from the meeting. Every meeting should have an agenda, adequate facilities, someone to take notes, and someone to follow up and hold everyone accountable.
Even effectively run meetings can be a drain on developer productivity if they shouldn’t be in the meeting in the first place. Some meetings can—and should—be handled via email instead of scheduling a specific time for an in-person meeting, and other meetings simply don’t require the input that the developer can provide. The solution architect, business analyst, or project manager can provide the input that the meeting requires, freeing the developer up to be productive.
Agile-Fall Meeting Types
Although these four meeting types might be appropriate for organizations that are committed to agile methodologies, there is a different set of meetings that happen inside of organizations which use iterative waterfall, blended agile-waterfall, or even traditional waterfall approaches. Even though the meetings may have different names, the purposes of the meetings are the same.
Daily standup meetings are frequently replaced with weekly status meetings that last longer and are less focused. The principles of knowing what was done, what will be done, and what is in the way are still essential to making status meetings effective.
The backlog planning meetings that happen each iteration are replaced with marathon estimation-planning meetings at the beginning of the project. These suffer from the competing objectives of scheduling the order and scoping as compared to estimating the work. By focusing the developers on the portions of the meeting that they can add value to through estimation, it’s possible to significantly reduce the impact to productivity.
Factors for All Meetings
In addition to the four guidelines that were mentioned above for traditional meetings (agenda, environment, minutes, and accountability), there are two additional keys that help developers be more productive. They are punctuality and scheduling.
Some teams have a penalty that developers must pay if they’re late to standup meetings. The penalty is designed to keep attention to the specific start time for the standup meeting. People who are chronically late to meetings—including standup meetings—waste everyone’s time by forcing them to delay or restart the meeting when they arrive. Although a minute may not seem like a big deal, in a 15-minute standup meeting, it represents more than 6% of the total meeting time. Developing a culture where punctuality is respected and expected will help all of your meetings start and end on time.
In the article, “Developer Productivity: Eliminating Distractions and Finding Flow,” I mentioned that developers need time to get into flow so that they can be their most productive. Scheduling meetings in most organizations is done in a haphazard way, with little thought to how developers need to work to be productive. If you can limit meetings with developers to two time periods in the day, such as one mid-morning for an hour (say from 9:30-10:30) and one mid-afternoon (say from 2:30-3:30), you leave large blocks of time that developers can get into flow and be productive.
Productive Meetings for Every Developer
Even though developers are ultimately responsible for their productive output, poorly-run meetings—and meetings they don’t need to be in—can represent a serious drain on productivity. By restructuring meetings a little, it’s possible to improve developer productivity and morale.