The unexpected effect of leaving Scrum

As a digital studio making UX/UI design and software development we have to face a big challenge:

Working for others.

There is just one thing that is even more challenging than this:

Working for others on multiple projects.

This means a lot of work must be done at portfolio level in order to apply the right resource allocation to projects using estimated duration (based on hours per person) as a main criteria.

So, just to explain a little better our job:

Working for others on fixed date, multiple projects with allocations based on rough estimates*.

*No, it’s not random. But very close.

How to make it work?

At the very beginning we used Basecamp to manage projects (yes, tasklists everywere). When we approached agile we did an in-depth study of Scrum framework and we tried to apply it to our team. After some months experimenting Scrum we found out it wasn’t a good fit for us.

The main reasons were:

1. High fragmentation of projects during the sprint caused focus problem in meeting the sprint goal.
2. Rituals took very long time especially during sprint planning because of high cost of switch user stories between projects.
3. Team morale was really going down because of the impossibility of completing features within the sprint, also because of urgency requests coming from production sites (expedite requests) that couldn’t really focus the team on the sprint goal.

tl;dr

Scrum was not the right fit for a team with project concurrency and expedite requests that sometimes had to be completed soon & quickly.

Who said Kanban?

The team moved to a pull project management system, Kanban (the book by David Anderson is a great resource to start). Kanban does not pretend to push the team towards a “deadline” result because it wraps the process around what you already have (in our case design/code/QA/deploy) and it works around lanes to make the work flow inside your development team (Trello is doing a great job in spreading how Kanban works in almost any situations). The basic principle in Kanban is very different from Scrum: you can work on something when there’s spot for that. This means that you begin to work on a card when you completed your current one or when your WIP allows you to do so.

It hasn’t been easy to make people understand the importance of moving cards from a lane to other on a virtual board and keep everything clean and up to date, but at the very end we structured and organized our development flow from design to code, to QA to deploy using WIP limits. No more sprint meetings and a big set of metrics for free: cycle time and CFD (LeanKit offers all of this in a very powerful web applications, not very beautiful from a point of view of UI but hey, you can’t get it all right?).

The “is-there-any-deadline-for-this” effect

An unexpected effect turned out at some point while we were using Kanban: team just settled down. In a pull system, theoretically, there is no real urgency nor focus on keeping the team committed to a precise milestones roadmap. It’s a flow. With Scrum, on the other hand, you have 10 days sprint, highly focus and highly committed team around the sprint cycle.

Therefor we felt the need to add an additional motivational layer: chasing a certain average cycle time is a good idea, but I find release milestones are closer, more understandable for developers and designers as a linear indicator towards the final release deadline. Let team members know the project roadmap within short-to-mid terms goals — better if wrapped inside the concept of cycles (weekly, 10 days…), this might seem trivial but in a pull system it can help the team to focus on common objectives.

What I’ve learned is that having a plan is better than having no plan at all; the important thing is to be prepared to adapt quickly during the project progress shifting release milestones with new periodic estimates. Milestones are a good linear indicator towards your final wanted release date and they should be kept in mind even in a pull system like Kanban.

This has been our direct experience and our attempt to adapt during our development process. I believe trying to manage concurrent projects inspired by agile methodologies is a problem that many organizations have to face, I would be very curious to know other patterns that aim at keeping the team focused on milestones with a “positive” pressure towards common goals.

This has evolved

These are some of our lessons learned. We are committed towards a continuous improvement about the way we work.

Read more on how this evolved.