Since I've started working in my current company, I've been researching, learning and mentoring about proper project management, while trying to find the best solution that could work within a digital agency environment.
I come from a purely Agile environment, such as SCRUM and XP, and my first steps when our team started to grow have been in that direction.

In this article I'll try to expose what had let me choose Kanban over SCRUM or XP for our digital team.

Why SCRUM (or XP) didn't fit

There are many reason why you might want to go Agile, using XP, SCRUM or any mix in between.

Some might be the ability to use time-boxed and controllable iterations, having meaningful deliverables at the end of each sprint, involve the client from the beginning or use a visual way to display what's going on using the SCRUM-board.

For us it didn't fit. Or at least not entirely… it was like something was still forced on us.

We felt like being Cinderella trying thousands of different shoes and none of them would fit, but hurt a bit.

Please be aware that I've used it and I still love Agile and its manifesto, for instance involving the client/stakeholders from the beginning throughout all the phases of the project or having sprint-retrospectives.

At the beginning I actually thought that eXtreme Programming would have been better than SCRUM: shorter iterations, more focus on the team values and loads of practices we could have picked. But that wasn't enough.

The actual problem is that we missed features when hitting the deadline, we kept having an ever-growing backlog nobody would actually remember to have (grooming it was a real pain, and it's not even the first time I see that happen in an Agile team). But the most important part is that while dealing with many active projects at the same time (from 1 up to 15), we lost focus on what we were doing and every stand up was difficult to deal with it: Has it been deployed yet? Why do we have that blocker there? and so on…

Some prefer to address these problems by making tickets more detailed in their content: 15 different fields to describe any aspect of the ticket. Others prefer to do a crazy breakdown until they reach the atom and have thousands of tickets on the board so they can see anything (and then you're welcome to deal with them).

We decided to take another road.

Enters Kanban

I was randomly looking at the dev blog at Mozilla.org and found an interesting article on how they moved into Kanban.

A ban came, its name was Kan.

It’s now more than a year we're using Kanban, and we're excited and pleased with it. It works the way you want (not as it wants) and it has given us a boost in confidence as a team as well.

Kanban defines only three basic rules:

1. Visualise your workflow
2. Limit your WIP
3. Measure the lead time.

I've created some simple slides to introduce my team to it, and I'll follow with some more articles on the subject of Project Managing as I've got a bit of articles material accumulating.

Let me know what you think of it or if there’s anything specific you'd like to hear about.