7 important meetings that your development team needs

Meetings—let’s face it, we usually hate them.

And it’s no secret why. Meetings can potentially waste a lot of time and money. Indeed, a Zippa research found that organizations lose around $37 billion per year to unproductive meetings.

The key to avoiding these harrowing statistics is to hold the right meetings the right way. For development teams, here are seven of the most crucial.

Project kick-off meetings

Project kick-off is the first meeting between you as the client and your development team when starting a new project.

The goal is to discuss all the relevant details, such as the timeline, deliverables, and scope.

Kick-offs are important because they set the foundation for the entire project. They help establish a common goal and set expectations for the team.

Plus, they’re an opportunity to tackle any potential roadblocks.

The biggest benefit of a kick-off meeting is that it helps reduce scope creep.

Scope creep is what happens when your team does tasks beyond the project’s needs, which could cost you more time and money.

And this usually happens when the team’s priorities and the project requirements aren’t aligned.

Source: Ignition

Kick-offs also help everyone get to know each other and establish social bonds. This is especially crucial when working with a remote team that doesn’t see each other in person.

Because of the importance of project kick-offs, all external and internal stakeholders must be present, including the development team, clients, and consultants.

Like any other meeting, a project kick-off requires careful planning.

For one, you need to write down the agenda for the meeting and send it to the participants beforehand.

This ensures that you cover all the critical points while still keeping the session as short as possible.

Here are some of the essential things to add to a kick-off agenda.

It’s best to start the kick-off with introductions, especially if it’s everyone’s first time working together.

Have every person introduce themselves and their role in the project team. Make it fun and light if you can.

Next, discuss the purpose—or the why—of the project. This is important because everything else should be in the service of this purpose.

After that, lay out the goals and objectives that your team must aim for.

With the foundation in place, you should discuss how you’ll achieve these goals.

You do this by talking about the deliverables, assumptions, tasks, estimated timeline, and budget, to name a few.

Most importantly, you should record everything discussed in the kick-off project.

That could become your template for important documents such as the statement of work and the master service agreement.

Sprint planning meetings

A sprint planning meeting is held at the start of every sprint, headed by the Scrum master.

As you know, a sprint is a mini-development phase that comprises the Scrum methodology.

It includes all the steps in a traditional software development cycle, from planning and testing to deployment or moving on to the next stage.

Scrum process

The sprint planning meeting is critical for defining the objectives and expectations for every sprint. It discusses every detail, from the deliverables to the strategy for fulfilling them.

In a way, this meeting can make or break the entire sprint. For example, deciding to work on the wrong tasks can delay the entire project.

Because of this, you need to be thorough with the process.

Start by picking tasks from the product backlog. This is a list of all the pending tasks according to priority.

Once you’ve decided on the tasks you’ll tackle, this becomes your sprint goal that goes into your sprint backlog.

After the goal is set, you can discuss how you’ll meet them in the current sprint. You’ll also need to anticipate any bottlenecks and propose solutions.

Additionally, the product owner might also chime in and give their insights on how they need tasks to get done.

It’s also good to look at previous sprint reviews and client feedback during the meeting.

How long should a sprint planning meeting last?

As a rule of thumb, no longer than two hours per sprint week. So, for example, if your sprint duration is three weeks, the meeting should be six hours at the very most.

Daily stand-up meetings

A daily stand-up meeting is a short 15-minute session where the development team gives a quick update on the project’s progress. It’s one of the critical meetings in the Agile methodology.

The goal of the daily stand-up is to keep everyone aligned. For stakeholders and team leads, it’s important because it lets them gauge if the project is on track.

For the team, it’s also a way to discuss key current issues in the project.

Because the daily stand-up meeting is so short, the agenda must be concise and on-topic.

One way to do this is to stick to only three questions:

Daily scrum meeting

“What did I do yesterday?” is a question that reveals the project’s progress to stakeholders.

If the team is falling behind in their tasks, it’s an opportunity to adjust the timeline or investigate the underlying causes of the delays.

“What will I do today?” is a question that helps the team synchronize their tasks. Announcing what each member intends to do makes everyone accountable.

Lastly, “Is there any impediment?” is a question that reveals any obstacles that might hinder the team’s progress. As such, the team can decide to prioritize tackling them.

When answered right, these three questions cover everything you’ll need to know in a daily stand-up.

However, the keyword here is concise. You don’t want to turn a daily stand-up into an hour-long status report.

If a team member is going into a lengthy blow-by-blow account of a problem, it’s the Scrum master’s job to remind them to keep it snappy.

There are other meetings for that purpose (which we’ll cover in later sections).

Demo meetings

In a demo meeting (also called a sprint review), the development team presents a work-in-progress to the client.

This type of meeting is usually conducted at the end of every sprint to get the stakeholders’ feedback or approval.

Here’s the flow of a typical demo meeting:

Sprint review meeting

Demo meetings are one of the most vital aspects of the Agile methodologies—and a big reason why they work so well.

That’s because these sessions are a way to get the client involved. It allows you to get their insights and incorporate them early on instead of waiting until the end of the development cycle.

For example, the DECODE team holds demo meetings once every sprint, where our developers can show new features to the client.

We also send a working demo to the client so they can test it themselves.

This hands-on approach generally leads to a better result with faster buy-in from the client.

Demo meetings are good for the team, too. Seeing the client appreciate their hard work can improve their morale.

On the flip side, if the client has issues with the demo, that gives the team clarity on how to fix it.

However, it’s important to show only the features you’re working on in the current sprint, not the entire project.

This can help the client review much more thoroughly and give focused feedback. Also, try to keep demo meetings between two to four hours in length.

Problem-solving meetings

Problem-solving meetings are sessions where project roadblocks and challenges are discussed in-depth.

It’s a key component in the decision-making process, depicted below:

Decision-making

Getting various roles into the meeting is advantageous, as it opens you up to more perspectives. For instance, it’s good to have non-technical members present as well.

Every meeting should start with the description of the problem you want to solve. Gather as many details about the issue as possible during this step, including any constraints.

It’s also crucial to know why something is a problem. Gauging the severity and impact on your project can allow you to prioritize which issues to solve first.

Next, brainstorm and shortlist potential solutions. The danger in this phase is getting into too much detail, prolonging the meeting.

You can do this by telling people only to describe the gist of the solution and not the actual steps.

Source: Lucid Spark

Finally, it’s time to make a decision. Here, you pick the ideal solution for your problem, given the constraints and situation.

It’s important to get buy-in from every member at this step to ensure the solution gets implemented correctly.

These three steps are the basic framework of any problem-solving meeting.

But if the problem you’re tackling is complex, separating each step into individual meetings might be a more efficient use of your time.

For instance, you can dedicate a one-hour meeting to defining the problem, then give everyone a day or two to brainstorm solutions, before meeting again to shortlist solutions.

Retrospective meetings

A retrospective meeting is when team members analyze and reflect on their performance in a previous sprint or development cycle.

The goal here is to spot problem areas and opportunities for improvement.

Here’s another way of looking at it: if a demo meeting reviews the software, a retrospective meeting reviews the team itself.

The big benefit of a retrospective meeting is that it creates a safe space for talking about sensitive topics, such as poor performance or disputes.

The purpose is not to blame people but to find the best solutions and improve the team.

Here are some concerns often raised in a retrospective meeting:

Sprint retrospective

As you can see, a good opener is to ask what went well. Starting with the positives is great for putting people in a more optimistic mindset for discussing more negative concerns later on.

Plus, it’s a great way to keep team morale up.

After that, you tackle the things that could be improved. Team members may bring up issues they faced with the project and their peers.

This is arguably the most sensitive part, as things could heat up and arguments ensue. Thus, it’s vital to have a skilled facilitator present.

Lastly, brainstorm strategies to improve these issues and write them in an action plan after the meeting.

This is a list of things your team needs to do or change based on outcomes discussed in the retrospective.

Make sure it’s visible, so everyone is constantly reminded of what they should work towards.

The key to retrospective meetings is not to make them an avenue for complaints alone. You should pair it with a healthy discussion of how to tackle and avoid them in the future.

One-on-one meetings

Sometimes, some issues are too sensitive or confidential for the entire team to hear. This is where one-on-one meetings between a developer and the manager come in.

The private nature of one-on-one meetings makes it a great opportunity to discuss details beyond the project.

You can talk about their performance, career prospects, future plans, and salary.

One-on-one meetings are perhaps one of the most effective management tools in your arsenal.

Employees appreciate such meetings, too. A study by Hypercontext found that 58% of employees felt motivated after a one-on-one meeting.

Your primary goal with a one-on-one meeting is to build trust. Your employee must feel safe in opening up to you. Address every concern and assure them that things will stay off the record.

It’s also best to schedule one-on-ones regularly, so people will know to anticipate them.

For example, DECODE conducts it every three months to gauge the effectiveness and well-being of our developers.

Finally, document everything. It sends the message that you’re taking the developer seriously. Plus, it will allow you to track their concerns over time.

One final thing to remember— the purpose of one-on-ones is not to judge or evaluate your developers. The focus is to help them improve.

Meetings can be a powerful tool

If conducted properly and concisely, meetings can be an effective way to boost your team’s effectiveness.

The seven types we discussed here are a good place to start.

Of course, it takes more than a few meetings to manage your team successfully. You’ll need a slew of strategies, best practices, and methods to get it right.

If you want to learn more about managing a software team, check out our articles here and here.