Scrum? Kanban? It doesn’t really matter

Over the past 8 years I’ve developed in both Scrum and Kanban.

There were times when I preferred Scrum over Kanban and times when I preferred Kanban over Scrum.

About two years ago, I came to an interesting conclusion — it doesn’t matter what you call it as long as you apply the right principles.

Scrum vs. Kanban

A personal story, I started my career in a Scrum team. It worked brilliantly (I have written many posts about Scrum) until we started working on a new, very important project. The requirements changed all the time during the sprints and the estimations were way off, since we were working on unfamiliar domains.

So we decided to do the only reasonable thing — switch to Kanban (I have also written about Kanban). In Kanban, we didn’t have sprints and we were fine with constantly changing requirements; we were always working on the most important tasks. But there were two problems : We were working only on the most important tasks and we were always working.

Since we always worked on the top priority tasks, we had no opportunity to work on anything but new features. We had no time to work on our tech debts or time to improve our tools and infrastructures.

So we decided to do the only reasonable thing — switch back to Scrum.

Well… you get the picture.

Disclaimer

I’m exaggerating; it wasn’t that bad, but it felt wrong no matter which one we chose. Neither of them was perfect and we constantly felt something was missing from our process.

The Best of Both

After experimenting with both, and seeing both Scrum and Kanban work and fail in lots of teams, I’ve came to realize that it doesn’t really matter what method you choose — the principles and the best practices are what matters most. So here are the principles that matter most for me.

It is important to finish

In Scrum you work with sprints, and every week or two the sprint comes to an end. This is one of the most deficient parts of Kanban in which we were constantly working; we finished tasks but we immediately started new ones. A sprint creates a scope that eventually ends. We all go home with that sense of accomplishment (even though we are going to start a new one after the weekend).

Celebrate wins

Another great principle is the review where you meet with stakeholders and share what you have accomplished in the last sprint. It is a celebration of everyone in your team, they get to share what they have done and receive feedback for it.

Constantly learn and improve yourself

The single best practice is to retrospect yourself. Think about what you should keep doing and what should you stop doing and improve. When you constantly work you don’t always get to stop and think about these things, hence you don’t improve. A retro is a must have meeting.

Requirements will change

In the real world, requirements change all the time. Bugs, features, the scope will constantly change. It is OK. This is the real world; we build, we measure and we learn. So it is good to change priorities and work on what really matters. Don’t be closed to changes — embrace them. And that brings me to the next point.

Plan ahead and break down to small tasks

It’s hard working on big, unfamiliar tasks. You cannot estimate the required effort or even truly understand the scope. The solution is simple — don’t do it :) Don’t dive into an unfamiliar area without the proper preparation. Don’t try to deliver right away. Start with a few hours exploration task, understand the scope, the requirements, the pitfalls, break the feature down to small deliverables and create a high level design. Share it with your team, poker plan them and you’ll see that estimating these tasks is pretty easy.

Visualize and share the process

Your process should be visible, both to your team and your stakeholders. Everyone should be able to easily understand what you are currently working on, what your next tasks are and what is blocking you. A visible process is key to spotting bottlenecks, dependencies and creating order.

It doesn’t matter what you call it

So, you see — you can use Scrum but don’t be afraid of changes and unknowns — embrace them. You can also use Kanban, but every once in a while stop, share your work, celebrate your wins and think if anything can be improved.

You can call it whatever you want. I call it Agile and sometimes Lean and sometimes simply work :)