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: How to make Shape Up successful?
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.
What happens next in the book is getting oriented, which explicitly says the 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 up front. If it doesn’t work, then there are 3 basic strategies to deal with it:
Time block the calendar before the kickoff and ask everyone to read the pitch in this timeframe.
Use Amazon’s idea to start the meeting silently by reading the document.
Accept the fact and waste time.
Writing is essential
Before starting the meeting, we want to ask 1 person to tidy up all the notes. The 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 have 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 proper team-level collaboration.
Speaking with no writing is a waste.
Kickoff Agenda
The agenda for the kickoff is:
Present the pitch
Ask questions
Convert pitch into Imagined Tasks / Scopes
List down Known Unknowns, Unanswered Questions, Risks
Write down the Project Goal
Agree on Ways of Working
Choose the First Problem To Tackle
Summarise
Let’s go through each agenda item 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 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 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.
You need to list all the tasks you think you will need to complete and group them into 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 of keeping the high tempo of the meeting and not making people fall asleep.
During this conversion, we make a team-level agreement on understanding 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. It is usually worth spending even 3 minutes speaking about the release strategy during the kickoff. 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 consider each unknown a separate task someone must 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 the Project Goal at 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 mentions the existence of existing products, new products, R&D, production modes. You get a shared understanding of the mode by asking for the goal. Also, Project Goal will make the scope prioritisation and hammering much easier.
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.
We may slightly change the team’s composition between the cycles when working in Shape Up. 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:
What’s your role in the team, and what can you bring?
What kind of project leadership do we use in this project?
What do you expect from the other people in the team?
How are we going to communicate, report and give feedback?
Do we want to work async, with meetings on-demand, or do we schedule some meetings right now?
Are there any non-software risks that we see?
Are there any other stakeholders in the company that we should keep in the loop?
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 first clarify which problem we will tackle. 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.
Explicitly name it and write it down.
We are sure the team members will go in this direction after leaving the meeting.
Step 8 - Summarise
Finally, you may quickly summarise 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 disorganised.
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 must raise stress and engagement levels 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.
