How we kicked off Spaces at N26

Context is everything when it comes to developing new features for customers. Unfortunately you’ll sometimes find the vision and aim of a particular product are encased in only one or two peoples heads. Creating transparency and clarity around new topics can not only speed things up, but provide real value for the customer.

No matter how great your backlog is, and how perfect your user stories are, it’s incredibly difficult to ensure that the whole team building the product truly understand what it’s all about.

The idea that a two hour kick off meeting and a pruned backlog will create the best results, and more importantly, the desired results, is completely false.

When we kicked off Spaces, we knew it would be essential that every team member was aligned on why we were building it, what value we hoped it would bring, who we were building it for, and what problems we are actually trying to solve.

It’s important that our teams see the bigger picture. What’s the business value? What KPI’s are we trying to drive? What customer value do we hope to deliver? Why?

Heavily inspired by Jonathan Rasmusson’s work around this topic, we dedicated time for the team to get together before they started delivering Spaces. We call this, as Rasmusson does, the inception.

It’s never a one size fits all process. We tailor our inceptions to the specific products. However, the outcomes we aim to reach are the same.

The Four Main Goals

1. We take the time to communicate the goals, vision, and context of the upcoming initiative.
2. We try to understand risky areas. As we scale it’s important teams understand how their work impacts other teams, and how other teams impact them.
3. We enable the team to make informed decisions while executing the work. This relieves the pressure on the PO to be the only point of contact when people have to make decisions.
4. Most importantly we validate ALL assumptions around the particular topic. When new topics come up, news travels fast and you can end up with a case of “Telephone” where the message gets distorted and people have already assumed they know everything there is to know.

Here’s what we wanted the team to achieve each day for the Spaces Inception. This is not a golden checklist that will solve all problems but simply a guide we found worked for the specific team, and specific initiative.

Day by day breakdown

Day 1: Purpose

• Team understands and is aligned on business value
• Team understands and is aligned on customer’s problems
• Team sets their measure of success
• Team shows the benefits they will provide to customers
• Team understand understand who they’re building for

Day 2: User Satisfaction

• Team understands where we are right now, and where we need to go
• Dream feature list is constructed
• Features are clustered into early stage Epics
• Team begin’s their ‘Not’ list — focus on what brings value first
• Team identifies key dependencies and stakeholders and begins internal discussions with them

Day 3: Technical Solution

• High level solution is sketched out
• Risky areas are identified
• Potential bottlenecks have been identified
• Overall solution is decided on, and team is aligned on what we need to do
• Request for Comment document is started and shared with wider organisation

Day 4: Breakdown

• Team has broken down the main chunks of work
• We have clearly defined Epics and Stories
• We know which chunks need to be shifted first
• We have our stories mapped

Day 5: Forecast

• High level estimates have been conducted
• We understand what our MVP aims to achieve and how long we might take to get there
• All learnings from inceptioned shared with wider stakeholders

Learnings

Initially it was tough to convince the team that 5 days was a necessary time to be away from coding. It was key that the PO felt ownership of the processes as well, and the combined effort made the whole inception much smoother. Making sure that the value is seen by the team is essential. Otherwise people can tend to see it as a bit of a holiday and aren’t fully focussed.

The way we approached this was to hold a futurespective. The team had prior knowledge we were going to be taking time to kickoff a new product. We gathered everyone and asked them what they hoped to achieve, and what their concerns were for the kickoff week. Taking their feedback onboard we shaped the experience around their needs.

Once we started we realised just how intense the process was. It was very tiring, but the end result helped the team massively. Every member of the team could explain why we were doing what we were doing, what problems we were solving, and how they were going to implement it. This sped us up massively during planning, during the sprints themselves, and gave the PO some respite of having to constantly answer worries and concerns around decisions.

Reflecting on the week we had two major learnings. Involving stakeholders is extremely important and we should have given this more attention. In preparation for the next inception we had a light 1 hour session identifying where we felt dependencies and invited those people to be part of the inception. Obviously in a busy organisation its essential you do this in advance so that they can clear their calendar and attend.

Another key learning was take the inception offsite. The days we were out of the office, the team was much more focussed. It’s hard to fully focus on topics when you’re in a context where you’re usually available to answer any questions outside the team.

You’re probably never going to find the perfect solution. It’s important after anything you do like this that you gather data at its conclusion. Find out what went well, repeat it. Find out what the limitations were and tweak it. As long as you make sure it’s about collaborating to ensure the customer will get the maximum value you’re on the right track!

Interested in joining one of our teams as we grow?

If you’d like to join us on the journey of building the mobile bank the world loves to use have a look at some of the roles we’re looking for here.