Shape Up, How to do a Project Kickoff?

It is one of the articles in the Shape Up series. For Table of Contents go to: Shape Up, Introduction

We’ve got a few projects to be delivered in the Building phase. The development team has assigned specific people to work on Project A. How to start it?

Kickoff by the book

After the betting table, Shape Up mentions the need to post a kickoff message and I agree with it. I wouldn’t use the word kickoff for that, but the idea is correct.

What happens next in the book is getting oriented, which explicitly says the very first days will not look like work. After some time, Ryan Singer wrote an article on Systemizing kickoff. The structure mentioned in Ryan’s article may help you a lot - but there are a few items which I recommend adding.

The article below describes the structure of the perfect kickoff, which enables the whole team to be effective just after leaving the kickoff meeting without making the very first days not look like “work”.

Recipe for Shape Up Project Kickoff

First, I am a massive fan of async work and low-meetings culture, but Project Kickoff is the Meeting.

Before the kickoff

Everyone must read the pitch before the kickoff meeting.

By reading the pitch earlier, people will process the pitch in their heads and come up with better questions.

If the team members keep coming unprepared, I recommend explaining the importance of reading the pitch upfront. If it doesn’t work then there are 3 basic strategies to deal with it:

1. Timeblock the calendar before the kickoff and ask everyone to read the pitch in this timeframe.
2. Use Amazon’s idea to start the meeting silently by reading the document.
3. Accept the fact and waste time.

Writing is essential

Before starting the meeting, we want to ask 1 person to take care of tidying up all the notes. The whole meeting must be a collaborative session where the screen is being shared, and many people use their keyboards to create a shared document.

The worst thing that may happen is letting all team members create private notes and keep them secret. As a result, we end up having a group of individuals with separate plans for the project. The only documents that matter are the shared ones. It is mandatory if we want to build the proper team-level collaboration.

Speaking with no writing is a waste.

Kickoff agenda

The agenda of the kickoff is:

1. Present the pitch
2. Ask questions
3. Convert pitch into Imagined Tasks / Scopes
4. List down Known Unknowns, Unanswered Questions, Risks
5. Write down the Project Goal
6. Agree on Ways of Working
7. Choose the First Problem To Tackle
8. Summarize

Let’s go through each agenda items one by one.

Step 1 - Present the pitch

The common pitfall is asking at the beginning of the meeting if everyone’s read the pitch. After getting a confirmation, we jump into asking questions.

This way, we risk having people who haven’t read it and are afraid to say it loudly.

Even the ideal writers, when presenting something verbally, tend to add details that haven’t been written down and they paraphrase what they’ve written. Team members may experience many aha moments during the presentation, so before letting the audience speak, it is worth letting the pitch owner tell the story.

I prefer to ask people to note down the questions and not interrupt the presenter.

Step 2 - Ask questions

After the presentation, we may go to the Q&A session on the pitch.

Many of these questions will be answered during the meeting, and some will not. Make sure to take notes.

We do not want to update the original pitch with the new knowledge because it makes it hard to spot the updates. The better way is to create a separate page with kickoff meeting notes.

Step 3 - Convert pitch into Imagined Tasks / Scopes

Shape Up calls it Imagined Tasks, which means the scope of work, we can predict before getting our hands dirty.

List all the tasks you think you will need to complete and group them into the Scopes.

I find the issue trackers like Jira too heavy for this step. Real-time-text-editing tools like Notion, Google Docs or any knowledge management software will do a better job to keep the high tempo of the meeting, and not making people fall asleep.

During this conversion, we make a team-level agreement on how we understand what needs to be done. We accept that the list isn’t complete, but that’s fine - the Discovered Tasks will appear during the project.

It is worth thinking not only about the functional aspects but also about the project’s release. Spending even 3 minutes speaking about the release strategy during the kickoff is usually worth it. Often, it improves engineering practices and leads to the earlier deployment of the feature to production.

Step 4 - List down Known Unknowns, Unanswered Questions, Risks

During the previous step, many unknowns, questions and risks were spotted. Note them down.

You may create a separate section/scope for it in your document. During the project, someone will need to find the answers to them. We may think about each unknown as a separate task someone will need to take care of.

Step 5 - Write down the Project Goal

Previous scoping steps are very involving, and most teams lose focus on the project’s initial goal during them. I find it helpful to bring the people back to the big picture by asking them to write down the Project Goal on the top of the page.

By the Project Goal, I mean a two-sentence summary of why we are working on this project and what we want to achieve.

This step often helps the teams clarify the proper working mode for the project. Shape Up mentiones the existence of existing products, new products, R&D, production modes. By asking for the goal, you get a shared understanding of the mode. Also, Project Goal makes prioritisation easier, which will need to happen soon.

Close the scope for now

At this point, park the scope and not think about planning its execution. We will get back to it soon.

Now, it is time for…

Step 6 - Agree on Ways of Working

This topic doesn’t exist in the Shape Up book.

Tuckman’s cycle describes the process of building the team as forming-storming-norming-performing.

When working in Shape Up, we slightly change the team’s composition between the cycles. At the beginning of the new cycle, we must help the team move through these stages as soon as possible. Most teams will waste the project’s first days if we do not do it.

Create a Miro/Document exercise that will ask the team to answer the following questions:

1. What’s your role in the team, and what can you bring?
2. What kind of project leadership do we use in this project?
3. What do you expect from the other people in the team?
4. How we are going to communicate, report and give feedback?
5. Do we want to work async, with meetings on-demand or do we schedule some meetings right now?
6. Are there any non-software risks that we see?
7. Are there any other stakeholders in the company that we should keep in the loop?
8. Do we need to do a separate project planning session?

By addressing the questions above, you get a shared understanding of how you will collaborate. It is a Project Team Contract.

Now, you can focus on delivering.

Step 7 - Choose the First Problem To Tackle

Before leaving the meeting, we must clarify which problem we will tackle first. If we do not do it, many people will work on not valuable parts of the project. Getting this strong agreement and focusing on the most significant risks first is essential.

Explicitly name it and write it down.

Now we are sure that the team members will go in this specific direction after leaving the meeting.

Step 8 - Summarize

Finally, you may quickly summarize all agreements and let everyone know where the notes are available.

Congratulations, you have nailed the kickoff.

Importance of Kickoffs

From my experience, poor kickoffs are the root cause of many issues for the Shape Up teams.

Because of not doing them effectively, many teams waste the project’s first days being disorganized.

This meeting is here to bring all the questions and agreements into a single session on the first day of the project.

Without running kickoff effectively, you’re taking a massive risk of not finishing projects on time, and you will end up closing the projects and fixing bugs during the cooldown.

Why not do it right so we can use cooldown for learning opportunities?

Key learning from project management

Years ago, as a project manager, I learnt that PMs, who live in constant stress, tend to take the beginning of the projects easy and move all the stressors to their end.

To help the team have a happy life, you need to raise the stress and engagement level in the project’s early days.

An effort taken at the beginning will save you sleepless nights at the end.

What’s next?

Above, I mentioned project roles and leadership modes. That’s the topic of the following article.