Blog

Kick-off’s are a great way of bringing a new team together at the start of a new project or phase of a project. The aim is to allow the team to get to know one another and to allow all the team members to understand the goals and objectives.

I recently helped facilitate a kick-off for the alpha phase of the ‘Protect’ service (working title). Although Protect had been through a discovery phase, circumstances meant that the Alpha team was quite different to the Discovery team. This meant that we needed to spend more time than perhaps usual bringing everyone up to speed. Our kick-off lasted 3.5 days. the structure was:

Day 1 (half day). High level overview and get to know each other. Day 2. User’s and organisational goals. Day 3. Look for opportunities and map a flow. Day 4. Build a hypothesis driven backlog and do a retrospective.

Monday

Most of the team had to travel Monday morning so we started in earnest at lunchtime. We had deliberately hired a space away from the office to avoid distractions and to help free up the teams thinking away from their usual workspace and routines.

The goal of Monday was to set the scene of our project within the wider context of HM Land Registry’s transformation programme, and to allow the team to get to know one another and how we like to work.

Scene setting described:

• What the digital programme is seeking to achieve and what is expected from us.
• How long the Alpha will run for.
• A high level view of what we learned in Discovery.

Once the scene was set, we did a ‘What are we seeking to achieve in Alpha.’ Session. This involved the team jotting down all the outputs and outcomes we expected to produce by the end of Alpha. This ensured the team understand the problem space, and helped get buy-in to what needs to be done.

Finally we ran through ‘A user manual for me’ session by Cassie Robinson. This helped us get a feel for how each of us likes to work. Based on that, we generated a team charter to help us reflect on how we work in future.

Tuesday

Tuesday was user research day, the aim of the day was to understand who the users of our service are, and what expectations and motivations they have.

We spent time going through the user research outputs from Discovery. This allowed us to get a feel for what our users found difficult, and what their expectations were when they used the service.

We did an exercise to look at the process from a fraudulent persona. How would we take advantage of the current system? It was a lot of fun pretending to be ‘evil’ but it also drove home some of the challenges we face in protecting citizens property rights.

At the end of the day we had a quick checkpoint to ensure we were on track and we were getting out what we expected to from the outcomes we had identified on Monday.

On Tuesday evening we went out as a team for a meal, to get to know one another better in a non-work context.

Wednesday

The aim of Wednesday was to get into the problem space in more detail. We started with the current flow for the service and identified the obvious risks and opportunities that the flow presented. The previous days persona exercises really helped with this as we had a lot more empathy for where the process would support or fail people.

Next we mapped out a new flow, this was hard. There are some difficult technical and usability challenges we face and we found ourselves going down a few rabbit holes. It wasn’t until Gordon, our architect, suggested mapping out what we think the perfect flow would be, then identify the challenges, that we really managed to get into what the service could look like. We succeeded and had a white-boarded service journey by the end of the day.

Thursday

Thursday was backlog building day. We now understood our users, had a proposed service journey, and a good feel for the technical complexity. How were we going to verify that this was correct though?

We chose to use Hypothesis Driven Development as a way of structuring our cards. The template was:

We believe that {the hypothesis} will allow {the outcome of the hypothesis} we will know this is true when {the measure of success}.

The beauty of this model was that we weren’t committing to outputs, but outcomes. Some of what we hold to be true at the beginning of the project will undoubtedly turn out to be false. The important thing is to identify early and cheaply what is true and what is not. The other nice thing about this style is that it worked for both technical and non-technical stories.

Of course as with any system, there were certain exceptions that disproved the rule. We didn’t get hung up on that, if there was a task to be done that was a no brainer, we just captured it instead of fretting about getting it to fit the format.

All models are wrong, but some are useful. — George Box.

Finally we ran a retrospective to discover what had worked well and what we could improve for next time. We used the retrospective sailing game to identify what had gone well, what was slowing us down, what we were worried would get in our way in future.

10 things I learned from the kick-off.

• Space to think and concentrate is important, booking external space really helps.
• Have a plan for the week, but dont be afraid to let things run if its going in a good direction.
• Have a large room with desks in the central area to make conversations easy.

• Lots of wallspace is vital, but have paper or magic whiteboard at hand.
• A projector gives you flexibility to bring up stuff on computers on any wall when needed and doesn’t clutter the space like a television.
• Spending time understanding users and their needs before diving into the service helped us validate how our proposed flow would work for them.
• Avoiding going down rabbit holes is a good skill, but in kick-off it can be necessary to go a little bit down rabbit holes to rule things out, or understand potential issues.
• Encourage everyone to contribute to the vision, objectives and direction of the service. They will be much more committed to its success.
• Make time to get to know one another as part of the working period, but also socially, this helps gel the team.

• Injecting a sense of urgency, but also enthusiasm for what we are doing is vital.