The first time I had to use an agile methodology was in 2009 when I was working in a company from Germany as a web developer with a small team of 4 people. I was introduced to that weird methodology called “Scrum”. What I got in that time from Agile is that we had to complete a form with 3 questions, then we had to share the answers during a daily meeting. In that time, I found it useful to sync the team, but other than that, It seemed useless for me as a developer.

I didn’t know the concept “Agile” was going to be so popular in the following years. I started to see the “Agile” methodology everywhere, everyone wanted to follow the “Agile” rituals. Therefore I started to document myself, read books about the different methodologies, and adapt the ones that could work more for my case. Despite I used Scrum several times, I realized It didn’t work for most of my projects, so I fell in love with the Kanban’s flexibility.

Scrum, Kanban, and Scrumban

If you go to the Scrum definition, you read something like this:

Scrum is an iterative and incremental framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.

“What is Scrum?”. What is Scrum? An Agile Framework for Completing Complex Projects – Scrum Alliance. Scrum Alliance. Retrieved February 24, 2016.

Did you notice “Product development” part?. It means that methodology was thought for products and a dedicated team working around the development of this piece of software. In addition to that, you have rules like:

• The team cannot be changed during the sprint.
• All the team members have to be working on the sprint only.

It works perfect for a company working around a single product, but in the real life of a software development company, It’s not feasible. 

Kanban seemed to be better for my team case. We need to release all the time, and not always the release is planned, and more if we are in production mode and we found a bug that needs to be fixed asap!

Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks.

Wikiepdia: https://en.wikipedia.org/wiki/Kanban_(development)

Okay, but if you manage work  according to the capacity, doesn’t it sound like work without a plan? It looks kind of disorganized. That’s why the term “scrumban” showed up, which means: plan like scrum but be flexible as kanban.

Development teams make big efforts to follow strictly all the rituals of any of these methodologies, and they don’t realize that when you are forcing to a methodology created by someone else, you are doing the opposite of being agile!

After several years working and living agile, I have realized that agile should be more about constant evolution because everything changes and if you stick to the same rules of 10 years ago, you won’t adapt to new requirements.

I personally like to  use a combination of Scrum, Kanban and extreme programming, and depending of the project or the company I use some ideas of each one. I’m not saying that you shouldn’t define rules, what I recommend is that you should define your own methodology for your team and embrace it, so the team is speaking same language and release great code.