A traditional project manager who was in the midst of becoming an agile leader asked me recently if I think agile projects should have kickoff meetings.
Yes, I do.
Becoming agile does not mean we need to throw out everything we've learned over the past 100 or so years of doing project management. Some things--project kickoff meetings included--remain valuable.
In this article, let's look at when the agile kickoff meeting happens, who attends, and what's discussed.
When to Hold an Agile Kickoff Meeting
I suggest holding a kickoff meeting whenever:
- A team is starting a major, new initiative
- A significant number of team members are new
- At least once a year
Major, New Initiatives
There have been arguments put forth that projects are dead and teams should only think about products. Even if that’s so, I contend teams still benefit from thinking about delivering batches of functionality. For example, a team may identify a minimum viable product as an initial deliverable. A larger set of functionality may then be identified as as “version 2” and so on.
For the purposes of this article, I’m considering each of those batches of functionality as a project.
When a team starts a major, new initiative, it can be worth holding a kickoff meeting.
The larger or more important the initiative, the more important it is to hold a kickoff meeting. A team migrating the company’s flagship product from a legacy to new technology would likely benefit from a kickoff meeting. A team adding a print button to four screens would probably not.
New Team Members
I don’t think a team of eight needs to hold a kickoff meeting when a ninth person is added to the team. But if a significant number of people join the team, conducting a kickoff will likely be worthwhile.
How you define “significant number of people” is up to you. I don’t have specific numbers or percentages in mind. A project that goes from 1 to 2 people probably doesn’t need a kickoff meeting. A project that goes from 20 to 40 (the same percentage increase) would.
At Least Once a Year
In my experience, having a kickoff meeting at least annually is helpful. I would do this even if no major, new initiatives have been started and if team composition had remained relatively constant.
This means that in deciding whether a kickoff meeting is warranted, you need to intermingle the three factors of how significant any new initiative is, the degree to which team membership has changed, and how long it’s been since the last kickoff.
Who Should Participate in an Agile Project Kickoff
Anyone who is officially on the team(s) should participate. That includes all programmers, testers, designers, database engineers, technical writers, analysts, and so on.
The team’s product owner should participate. So should the team’s Scrum Master or coach.
Beyond all these roles, there are two types of people who warrant special consideration in deciding whether they should participate: stakeholders and part-time team members. Let’s consider each separately.
Stakeholders
As we’ll see in the coming section on the agenda for kickoff meeting, there are some portions of the agenda for which it would be nice to have stakeholders present. However, I generally don’t find their full participation warranted. They aren’t truly needed for the full meeting, so it’s not a good use of their valuable time.
Perhaps consider including a couple of key stakeholders in the full meeting or inviting some to join a portion of the meeting. I don’t mind their participation. Rather I want to be respectful of their time.
Part-Time Team Members
There are clearly some people whose participation is so extreme, it’s obvious what to do. As exaggerated examples, a tech writer assigned to the product 1% of the time would not need to participate in a kickoff meeting. The same tech writer if assigned 99% ot the product, however, would participate.
The issue, of course, is the vast middle ground between these extremes.
As with nearly every issue created by spreading people across multiple projects, there is no easy answer here. I think each case needs to be uniquely considered and two questions addressed:
- How much will that person benefit from participating?
- How much will the team benefit from the person participating?
Each team will need to decide how much benefit is needed to require the person to participate. Beyond that, I find inviting all part-time team members and letting decide is the best strategy.
What’s Discussed in an Agile Kickoff Meeting
In looking at an agenda for an agile kickoff meeting, it’s important to structure the meeting to work well with distributed participants. A kickoff meeting is a great time for a distributed team to meet in person even if that means some participants have to travel.
But, it’s just not realistic to assume that it will always be possible to meet in person, so our agile kickoff agenda needs to work well even with remote participants.
Here’s my recommended agenda for your kickoff meeting:
- Introductions
- Scope / Deliverables
- Core and Desired Capabilities
- Collaboration & Communication Plan
- Risks
- Wrap Up
Let’s take a further look at what to cover within each of parts of the meeting. You can also download a PDF summarizing the agenda.
1. Introductions
Even when everyone knows one another, I still recommend starting with brief introductions. Don’t worry, this can be quick, probably 30–60 seconds per person. I like a three-part introduction:
- Share what type of work you did on your last project.
- Share a personal success since the team’s last kickoff (or within the past 3 or so months if new the team).
- Share a professional success from the same period.
So I might start by sharing what I contributed to the last project, perhaps, “I did a lot of the coding on the medical records part of the system. I helped a little on patient search screens. And I helped Ashish get some automated testing in place for some of the old code.”
Don’t let anyone turn this into a day-by-day summary of their work. This is meant to be equivalent of saying, “I’m a programmer,” which was fine on traditional (non-agile) projects.
But on an agile project, we don’t want to pigeon-hole people in silos of “I’m an X.” And having everyone say, “I’m a team member,” isn’t very useful. So team members briefly describe the type of work they did on their previous project.
A Personal and a Professional Success
Next, each person shares two successes. These are intended to provide insight into the real person. We often don’t know each other well enough; sharing both a personal and a professional success story counters that.
A personal success could be anything--something your kid or partner did, an athletic accomplishment, a health goal, a trip you planned, something you purchased, and so on. Each person simply names something unrelated to work that brought them joy over the previous period.
Then do the same with a professional success or accomplishment. Maybe you completed that online course on Linux administration, no bugs were found in your part of the product after it was released, you found last month’s story mapping meeting really useful, and so on.
2. Scope / Deliverables
Next, it’s often worth having the product owner explain what he or she would like delivered in the coming period, often a quarter or so. This shouldn’t be a walkthrough of an entire product backlog. In fact, the best kickoff meetings I’ve participated in don’t even get to the level of specific, individual user stories.
This should more be the product owner presenting a higher-level description of the work to be done in the coming period.
Suppose the team is developing a new word processor. The product owner might share this:
“I really want to have enough support for tables that we can release that and start getting feedback on the new table design. We don’t need everything for tables done but enough that we all agree it’s releasable. I think we also need to be done with the caching and other performance work we’ve talked about. If we can’t get to 100%, though, the remaining performance work is low enough priority that we can put it off for 3-6 more months after this.”
How Is Success Defined?
Important to this item on the agenda is a discussion of how the team will define success. There are many equally valid ways a team may do that including examples like these:
- Will we release during this period? Ideally, how often? Perhaps even on what date?
- What will be fully developed and delivered?
- What will be developed enough that a subset of it can delivered?
- What other deliverables are needed? Are there documents that must be updated?
- What quality level is expected? Is the project successful, for example, if the deadline is met but some low-risk (the team thinks) testing was cut?
Document the Project Vision
During this part of a kickoff meeting, I find it helpful to document the vision. This isn’t the whole product vision. Rather, the vision for what will be completed in the coming period.
Agile teams have historically used various lightweight approaches to this. Two of my favorites are writing either the product review or press release the team would like to earn by the end of the period.
To do this, the team imagines themselves at the end of period and thinking back on the project. What would they like mentioned in a press release, magazine review, or perhaps multiple app store reviews?
Identifying those items encapsulates an overall vision into a small set of the most important things to accomplish.
As an example, one team I worked with imagined themselves earning a PC Magazine “Editor’s Choice” award. They wrote the review they wanted to earn and then set about doing the work to enable that. These “vision reviews” were printed and displayed throughout the team’s workspaces.
When PC Magazine next reviewed their product, the team was indeed given an Editor’s Choice award. The review even singled out some of the same features the team had written about in its own vision review.
3. Core and Desired Capabilities
I remember attending kickoff meetings for non-agile projects early in my career. A common agenda item in those meetings was roles and responsibilities.
During that discussion, the project manager would outline each person’s responsibilities on the project. As a programmer, I was told I was responsible for
- writing “high quality code” (which was never defined),
- unit testing (hopefully),
- commenting my code,
- answering questions from testers about my code, and
- fixing bugs found in my code.
Identifying each roles’ responsibilities was usually helpful, but it never felt very agile.
What I recommend instead is having each team member state their core capabilities and their desired capabilities. For example, I might state that my core capabilities are writing Java code, working with the database, and testing. For any work of that nature, I’m available.
I might then add that a desired capability is doing more with Python. I’ve done a bit and can help but it’s not one of my core capabilities. I’m hoping to get more opportunities on this project, but everyone should be prepared that I won’t be as proficient at it yet.
I find that having each team member state what they are good at and what they’d like to become good at is a better, more agile approach than a traditional project manager outlining each person’s responsibilities for them.
4. Collaboration and Communication Plan
An important part of kicking off a traditional, non-agile project has always been creating a communication plan--who is responsible for communicating with which stakeholders.
To some extent that remains helpful on an agile project. But much of that is handled by sticking to a regular iteration review schedule, such as “every other Thursday at 3 P.M.” That lets stakeholders know how to remain current on project progress.
Even so, there are often some stakeholders who warrant specific, further, or more personal communication. And it can be worth identifying who those are and who on the team will communicate with them regularly.
Collaboration Within the Team
Beyond deciding on how communication with those outside the team will occur, the kickoff meeting is a great time to discuss agile teamwork: how team members will collaborate among themselves. This should include the following:
- Working agreements that define appropriate team behavior. This could include whether it’s important to be on time for meetings, whether it’s OK to use your mobile phone during meetings, how quickly emails should be responded to and so on. Any answer to these issues can be fine as long as it’s agreed to by team members.
- Which tools to use for which conversations. Discuss and come to agreement on which types of discussions are best suited for email, messaging tools like Slack, and so on.
During this part of the kickoff meeting, I also suggest agreeing upon process-specific issues such as
- The length of the team’s iterations
- The day of the week when iteration start
- The team’s definition of done
- Any work-in-process limits
and any other similar items.
5. Risks
Not every team will discuss risks and risk mitigation in its agile kickoff meeting, but I recommend teams at least consider it.
Risk management is not formally defined as part of agile frameworks like Scrum. And that’s understandable as a lot of risks do go away (or get exposed) with the short iterations common to agile. But there are still projects that benefit from lightweight but explicit risk management. I suggested starting that during the kickoff meeting.
This doesn’t have to lengthy or burdensome. I suggest asking team members to create a list of the top ten risks they can think of.
During subsequent iteration planning meetings, team members can revisit that list and decide if any specific risk mitigation activities are worth adding to any iterations. Risks can then be tracked and quantified on a risk burndown chart.
6. Wrap Up
At this point the meeting is officially wrapped up, normally by a Scrum Master or whoever else has been facilitating the meeting.
Most teams will be able work through everything here in 2–4 hours but definitely no more than a full day. That means that there will often be time for additional working sessions with team members who have traveled to participate in the kickoff.
Before concluding, the facilitator should, of course, thank everyone for participating. I also find it helpful to specifically ask participants if their expectations for the meeting were met. This can be as simple as each person in turn stating yes, mostly, somewhat, or no.
After each person shares a one-word answer, follow up with those whose expectations were not met. In some cases, this leads to an additional agenda topic that can be discussed right then or scheduled for a subsequent meeting or call.
Why Conduct a Kickoff Meeting on Agile Projects?
Why bother with a kickoff meeting on an agile project? Because a well-run kickoff meeting using the agenda I’ve described
- sets ground rules for how team members should interact with one another and their stakeholders
- helps everyone understand the purpose of project synchronizes everyone’s understanding of priorities
- establishes team norms regarding expected behavior
I find these compelling reasons to start each significant, new initiative with a kickoff meeting.
