Our Journey with Scrum, Kanban and all things in between

When I first joined Monese early in 2017, we worked in one week sprints and ran weekly planning poker sessions. The team would gather in a room and talk through stories, wireframes and estimate how easy or difficult they thought a task might be. In this weekly session, we also used to hold a retrospective and rate the sprint. What became clear after a few weeks was that these sessions were eating up a lot of time, most of the work would carry over unfinished into the next sprint, and we’d emerge with no or little action points from the retro.

Back in the Scrum days we were slow to ship releases. One particular build had been queued up for weeks and someone had forgotten to actually publish it on both Google Play and iTunes Connect. We didn’t have a focus on getting things from ready to done with developers context switching between multiple tasks. At my previous company, we had been successfully running Kanban and managed to push new updates out every few weeks to millions of customers. We decided to make the switch at Monese and here’s what happened — both the good and the bad.

The Good
Let’s start with the positives. Initially we were a small team with only 3 Android and 3 iOS developers. A switch to Kanban brought the following benefits:

1. We started focusing on finishing our tasks before moving on to the next item by limiting work in progress and reducing context switching
2. This meant we were able to ship new releases every 2 to 3 weeks and deliver value more often to customers
3. We saved time by cutting out weekly estimation sessions and instead moved to feature based kick offs
4. Retrospectives were feature/project based, and we emerged with more tangible action points
5. We were able to respond to production issues quickly and expedite critical bug fixes for same or next day release
6. Impediments got solved quickly as Kanban forces you to stop the line and remove blockers immediately

The Bad
Late in 2017, we expanded our mobile development teams and started to pull in more work and features. This started to result in the following issues:

• Continual scope creep on new features, the ready for dev column would continually pile up with new tasks and optimisations. No time-boxing meant tasks for a feature could continue push into the development queue
• We didn’t hold sprint planning or estimation sessions, therefore with scope creep and added tasks post kick off, it became difficult to keep track of project progress
• Developers started to context switch often with many tasks and bugs being deemed high priority or critical
• Estimations (whilst they are never accurate) become wildly inaccurate and this caused issues with stakeholders and our leadership team
• Kickoffs were too lightweight. The pull nature of Kanban meant that developers would just pick up the next task and often we didn’t scrutinise tasks enough before committing to the development work
• We started rushing to get tasks completed due to estimations running over, this then put pressure on test teams and often meant we had to ship releases with limited test windows

Learning points with Kanban
In retrospect, the switch to Kanban worked well when we had a small team and limited the work in progress which meant we could focus on finishing tasks and shipping more often. However, after this experience, and based on the feedback from the wider product development team, I believe Kanban is best suited in two scenarios:

1. For use with BAU work where you have a steady stream of predictable tasks and task sizes with no critical deadlines or pressure from business stakeholders
2. For use with highly mature development/feature teams that have worked together for a prolonged period of time and have a better idea of their strengths, weaknesses and the amount of work they can commit to in a certain time frame

In our case, once we started to increase the team size and had many people working together on features for the first time, Kanban became an unsuitable process for us as we were not able to guesstimate with even a hint of accuracy how long a project would take and it led to us skipping out the up front planning and sizing that a Scrum process encourages you to do.

So what are we doing now?
We’re actually moving to a squads/feature team based model with a number of different teams that include:

• Core Banking — Supporting key flows and tackling technical debt and production issues
• Growth — focused on growth related tasks and improving sign up conversion
• New Features — Dedicated to adding new features to the product
• KYC/AML — Working on enhancing the sign up experience for customers and fraud prevention

Core Banking for example, will be tasked with a number of BAU and technical debt tasks and therefore will be suited to using Kanban without estimations. The team can release regularly without any critical time pressures, with the exception of critical bug fixes.

However, our feature teams will have very clear goals and timelines that business stakeholders expect us to deliver against. Within these features teams we will introduce planning poker again, hold daily cross functional stand ups and work in weekly or bi weekly sprints. We will start by under committing in each sprint to get a good idea of the team’s velocity, and then we can start to provide better guesstimates to our business stakeholders so they can have better visibility of when we’re likely to ship features to customers.

We’ll still ship often — every two to three weeks and if a feature is ready it will hop on to the release train, if it’s not well it can jump onto the next release as it’ll be along soon enough.

Estimates, No estimates
Within the project management space, there are advocates for both estimates and no estimates. Without sounding too diplomatic, I tend to sympathise with both perspectives. Estimates and project plans are never accurate, they never survive first contact with the enemy.

In highly mature teams working on predictable tasks, historical data can be used to indicate how long work should take. In Kanban this is known as cycle time and can be measured from the moment a task enters the queue until the moment it’s done. You can also measure it in shorter cycles, for example from in development to done.

However, with new features or R & D projects tasks are never predictable, therefore it’s hard to model the project time based on historical data.

This is where estimation and a little bit of upfront sprint planning can be helpful. Here’s a few more reasons why estimates can be helpful, as long as they’re not taken as gospel:

1. Provides a realistic goal or target date for the entire team to work towards. People work better with goals rather than endlessly working on a task with no clear goal or deadline in sight
2. Provides some visibility to stakeholders as to when a feature will ship, as long as they understand it’s a rough window — it’ll ship in April versus it’ll ship on 23rd April at 2pm
3. Encourages teams to collectively estimate the complexity of tasks and agree on a score. Rather than being useful as a management or time tracking tool, this actually encourages people to think through edge cases and dive into whether a task is as easy or difficult as it appears

We’ll be trying this new approach in the coming weeks and months. Whilst we’re under no illusions that it’ll solve some of our delivery problems, it’ll be moving us forward in the right direction and we can learn from what works and adapt or change what doesn’t.

We’re fortunate that we have an awesome team of engineers, testers and designers at Monese, willing to adapt and try new approaches and even go back to some of our old approaches when some of the new approaches fail! If you’ve had any similar or different experiences with Scrum or Kanban, please share them in the comments below.

This post was written by Tom Barbour, Head of Product Monese . This is the sixth instalment in a regular series from the Product and Engineering team at Monese.