It’s no secret we like it agile. Delivering parts of the product in small batches instead of the entire product at once is ideal for the production team, the client and the user.

Like many teams do when they want to embrace agile, we tried running scrum — today’s most renown agile framework. But we felt like the process dragged us down a little bit and messed around with the planning and quality of delivery. We totally see scrum work out in product teams that lock themselves up in a war room for 40 hours a week. But we’re a small agency and often have multiple projects to focus on, so we most of the times we won’t be able to do that. That’s why we tried looking for an alternative.

Can we fix it? Yes, we Kanban!

Eventually, we found our glimmer of hope in the agile framework Kanban and made it our own.

The definition of Kanban

Kanban is an invention of Toyota, inspired by the model of how supermarkets stock their shelves. It aligns inventory levels with actual consumer demands. Kanban literally means ‘visual signal’ and that’s pretty much what it is. By spreading out cards (which represent work items) on a board with different lanes that stand for phases of the process, the team members can track the progress in the workflow. Kanban’s just-in-time principle make it particularly useful for software development teams to match the amount of work to the team’s capacity. There’s more focus, full transparency and it helps the team to get results fast.

How we run Kanban

Kanban offers us the solution to work agile and comes with many advantages. First of all, it makes the process of the entire product development team clear and visible by organising cards on the board. In Kanban we’re still setting up user stories (like scrum) and every story gets shipped as soon as it’s finished.

We can find solutions that are just right for the problem, yet have the urge to get things live as soon as possible.

We use Kanban to make priorities and tasks transparent. Tickets get divided in lanes, which all represent a phase in the agile production process: 

To do, Design, Verify, Ready for development, Development, Test, Done.

The product owner has the duty to fill and prioritise the backlog. The top tickets always get priority, so these will be added to the Kanban board in order of appearance. It’s a continuous process, which includes continuousdevelopment and product updates. The team’s success is measured in cycle time (the time it takes for a ticket to get from To do to Done) and this cycle time can be used to forecast the delivery of future user stories, so clients roughly know how long it will take for features to be implemented.

We still have some meetings. Once every week, we reflect on our progress and talk about what’s next for us. We discuss and brainstorm about the user stories at hand and make a rough estimation how long it would take for design and development. While we’re working on it, we plan some calls when we feel we would like to get an update or get some feedback. Because meetings only get planned when needed, overhead hours get reduced.

We use a parallel track approach, where the design work is always done one or two steps ahead of the development work. So, designers usually do their thing in a few days and the developers start implementing that feature after the designs got verified by the product owner. For designers, that’s great, because they get more time to carefully think it through and come up with a design that’s complete and correct. As a matter of course, developers and the product owner always get a seat at the table if it comes to decision-making in the design. We use planned meetings for that or just pull one’s sleeve if an opinion is needed. In the meantime development works on the designs that are finished. On their turn, they also can ask questions or present unforeseen problems to the team.

In Kanban it’s more important finishing a task than starting a new one. To stimulate that the team might come up with rules to optimize the workflow. For example not allowing for tickets to be longer than one day on Test and Verify. Or the team members might agree with one another that every lane gets a maximum on the amount of tickets.

The big advantage of Kanban is that there’s less time pressure. Unlike scrum, there are no biweekly deadlines to deploy stuff. We won’t have to put features live we’re not happy with yet. We can find solutions that are just right for the problem, yet have the urge to get things live as soon as possible as we still plan sprints and think ahead. Value is added to the product every time a ticket hits Done!

Kanban also provides us with some flexibility. Emergencies and sudden changes of direction, which often happen in start-up environments, are easier to manage. They just get higher on the board, thus get priority over other tickets. Emergencies will be pushed live first, then the regular work gets picked up again.

Kanban over scrum

In our situation scrum is a bit unwieldy. We can imagine, when you have a dedicated product team that works together full-time and a product that doesn’t take too much sudden direction changes, scrum would work out. The overhead hours the team members will endure would be relatively lower.

In an agency setting though (providing clients with many advantages and opportunities) we believe it’s just not worth it. For us, Kanban is a better fit. It provides a perfect overview of the tasks at hand, ensures good collaborations between client, design and development and provides continuous product updates. Less time pressure and overhead, more value!

Progress of process

Every day we’re encountering new pains and peaks in our process. That’s why we’re always looking for ways to improve. Yesterday’s process differs from tomorrow’s and that’s fine. Our agile process is just that agile, I guess.

We’d love to hear your approach on an agile way of working!

Can’t wait to start an agile project yourself? Or are you ready to include design in your existing agile process? We’re happy to be of assistance! Just give us a call.