We’ve all been there: you’re nearly done building that feature and you just need that last piece of information from a colleague to do the final part. You message them for it and their reply contains a subtle detail, something you’d overlooked, and which completely changes how the feature needs to work.
Or perhaps it’s a project with another team, which when you go to integrate the two parts don’t quite work how you’d thought, despite having agreed a specification for the interface.
Wouldn’t it be great if we could catch these issues earlier?
While many teams build up processes over time to deal with specific instances of this, building a project process from the ground up to address this sort of issue can be much clearer, simpler, and more effective as a result.
At Thread we have developed a process built around early consensus and a living specification document, which is then referenced (and updated!) throughout the project. We call these Kick-offs.
The ideal outcome from a project Kick-off is a written record of what the project is (as well as what it isn’t) which is clear to all those who will be working on, or have a significant stake in, the project.
This has a couple of consequences:
As early as possible (and sometimes sooner), the Kick-off meeting gets everyone that will be involved in a project on the same page regarding what the project is (as well as what it isn’t). When doing this well, it will bring together people from different disciplines and uncover unknowns about a project while it’s still easy to change direction.
At Thread, a Kick-off for a new site feature related to the personal styling ideas we present to a user might involve:
The length of a Kick-off meeting needs to balance being long enough to capture everything while also being short enough that everyone can attend. We’ve found that 30 minutes is a good length.
Sometimes we’ll find that 30 minutes isn’t enough time to cover everything we wanted — this is a signal that we’re trying to do too much in one go. Depending on the project, it might be that we need to break it into smaller pieces or to first do more research into what problem we’re trying to solve (yes, we would kick-off that research project too!).
In the meeting we work together to create the specification for the project. As a result, exactly what should be discussed in a Kick-off varies depending on the type of project.
The common theme is that we’re filling out a template document which contains prompts specific to the type of project. The document should be in a format which everyone can easily access, add comments to and edit (this is important after the meeting; we use Google Docs).
At Thread we have a few different Kick-off templates:
Each of these templates has a checklist of things to do before the Kick-off meeting, as well as section headings for things to discuss in the meeting.
Here’s an example of one of our templates:
The sections in our templates are informed by what we’ve found to be useful to clarify in the early stages of a project, as well as things we want to get better at always including in a project. For the template above, in additional to the main feature descriptions, there are sections specifically about analytics and monitoring.
Kick-off templates for other types of project might instead have prompts for how a feature would be translated, or what the SLA for the project is.
The prompts you include in a Kick-off will be specific to the types of project you’re working on and should be chosen to be ones which lead to useful useful discussions in your Kick-off meetings.
Even if you’re doing it well, you will sometimes find that you uncover new information or change you mind about things after the Kick-off meeting. This is normal!
When this happens, we share the new information with the project lead and work out what changes, if any, need to be made to the project. Even if we don’t change anything, we’ll integrate the new information into the Kick-off document.
This ensures that the document remains up to date as the reference for the project. As we use Google Docs for our Kick-off documents, we often have the discussion around the new information or questions within comments on the document further helps keep all the information in one place.
We find this particularly useful as we cross-link the Kick-off document from the entries in our project tracker and from pull requests. The latter allows it to provide context for the person doing the code review, so they have a better understanding of why technical decisions may have been made.
Over time we’ve noticed particular things which our projects are often overlooking, or which are in our Kick-off templates but which aren’t actually helping in our Kick-off discussions.
We’ve used these as opportunities to improve the Kick-off templates, by adding or removing sections as needed and sometimes creating completely fresh ones for new project types.
We’ve found that using Kick-offs has helped us catch a wide variety of issues early in projects and gives us confidence to move quickly once we start implementing. This allows us to achieve the spirit of agility, while also gaining many of the benefits of defining much of the project up front.