When you start work on a big project, you may get a sinking feeling as you think "big meetings." Team members don't like meetings because they are boring. Project managers don't like meetings because they take time to arrange, which can substantially delay projects. Businesses don't like meetings because they are very expensive in time and money.
But we still call meetings. They are efficient for managers, who only have to explain themselves once, rather than many times in many media. They also provide a place for team members to ask questions and get help.
When we go continuous and get rid of batches, like iterations and releases, we Unblock! and become more scalable. Meetings are also batches, and they block. Our teams will be more scalable if we reduce the number of meetings.
Let's look at some of the most common types of meetings and see how we can eliminate them or get more out of them.
A face-to-face kickoff meeting at the beginning of a project gives you a chance to present the big vision and goals of the project and answer questions. This is one of the most productive types of meetings, because it aligns everyone with the same goals. That makes your teams more effective. It is also a chance to answer questions from skeptics. You hope that it will launch contributors into productive work quickly.
However, the kickoff meeting comes at an inconvenient time, just when you want to get started quickly. If it takes time to bring people together for this meeting, you should not accept the delay.
You can do an online presentation that will be almost as effective. Present the vision, goals, plan and roles of the project, then take questions. Do not try to turn this event into a working and planning session. Your teams will do that later, after you have inspired them. Make the presentation, answer questions, then finish.
Make architecture proposals and prototypes before you do a kickoff meeting. Architecture is a solitary art, not a group sport. Your champions should bring solid proposals into any kickoff.
Your team can post "What I did," "What I will do today" and "What I need" on an online form. That saves a lot of time. After that they can hold an online chat and discuss needs and questions. As your team becomes more confident, they may eliminate the scheduled chat and just use persistent chat to post questions and victories as events occur.
I recommend that you keep the "what I will do today" reporting because it gives you a chance to see when people are working on low priority tasks and ask them to help with high priority tasks.
If you provide development services to clients, you probably do a weekly call with each client to show your work and report on how things are going. You will want to make this easier and more professional with a fixed format agenda, similar to the standup format. It is very important to include "what I need from the client" in this agenda. In a continuous process, your goal should be to shrink the number of people on this call to a very small number, such as two. To do this, you should provide ways for clients and service teams to communicate directly, in real time.
I recommend that you eliminate iteration planning meetings. They are a lot of work, and they are difficult for a distributed team. Instead, use a process like Scrumban or Kanban that allows users to pull tasks when they are ready to work on them.
Instead of doing an iteration plan with the complete team, take a smaller group of people and do "backlog grooming." This means making sure that your upcoming tasks have good descriptions, use cases, and design materials. Ask if they are still urgent and important. Present your implementation team with tasks that are worth doing, and the information they need for success.
You should arrange meetings to brainstorm and resolve problems, if they become urgent. These meetings are good because they bring together a selected group of people who are actually interested in the issue. One secret to getting enthusiastic participation is to not make meetings all about you. Make sure that a substantial proportion of the meetings are called for other people's problems. You should also show that the meetings are meaningful by following up on any recommendations coming from them.
If continuous improvement is a core goal, retrospective meetings are an important tool to figure out how to improve. However, for some reason most retrospectives are incredibly boring. Consider these alternatives:
These big cross-team meetings are a major weak point in applying Scrum to larger projects. They are useful (when they work) because they give people a chance to handle dependencies. If one team is waiting for something from a second team, they can ask for help and get a status update at the Scrum of Scrums level. But there are better ways to handle dependencies, which we will discuss in the next section.