Scrumban: The Solution That Fits My Team

If you have any issues with the methodology approach you have in your company, then you have probably heard these words already. That is our case as well. At a certain point in time, we felt like we were no longer facing the rapidly changing requirements that come from modern world business and that the software development methodology we had was pulling us back.

Agile

At that point, we decided that we want to be more Agile. What is Agile? Besides on what Wikipedia has to say about Agile, for us Agile is a state of mind and spirit first of all.

Agile vs. Scrum vs. Kanban

These words are often used together or even as synonyms for each other, which is not correct. Kanban and Scrum are both Agile software developments methodologies with similarities and differences. Some say that these are two different paths to the overall Agile goal. We think that they are more like two faces of the same coin – they are different, but they can sit together very well.

Essence of Scrum

Scrum, as a software development strategy, defines a set of explicit ‘rules’ of using it:

• Roles

  • Product Owner: the person responsible for the actual product future.
  • Scrum Master: the person who ensures that the team follows Agile Scrum principles.
  • Scrum Team: a self-organized and cross-functional team that develops the product.

• Artifacts

  • Product Backlog: contains a list of features that need to be implemented for the Product.
  • Sprint Backlog: a list of features to implement in the current Sprint.
  • Burndown Chart: a graphical overview of the current Sprint progress.
  • Product: a potential shippable product increment.

• Activities

  • Sprint: the time-limited period for implementing a set of features from the Product Backlog.
  • Sprint Planning Meeting: a time to plan, discuss, and organize work for the upcoming Sprint.
  • Daily Scrum Meeting: an update on current status of the Sprint.
  • Sprint Review: a demonstration the newly implemented functionalities.
  • Retrospective: seeing what was bad and how to improve.

Essence of Kanban

Kanban is primarily based only on four principles:

1. Visualize Work: build a visual model of the workflow (a Kanban board). This makes progress visible, along with bottlenecks and queues, and improves a lot the communication.
2. Limit Work in Progress: reduce the time it takes to pass a task through the Kanban flow by limiting the amount of work that is being done at a certain point. The visualization of the flow greatly helps in this.
3. Focus on Flow: the team is responsible for ensuring that tasks pass through the Kanban flow as quickly as possible. By analyzing data collected from the flow the team can determine where the bottlenecks are.
4. Continuously Improve: the practices should always adapt to the continuously changing requirements.

Our Decision

As you see, each methodology has its own specificities. Scrum is noticeable by the amount of "rules" it defines. And this is actually very helpful if you are stuck with your current methodology and need a change. This was our case as well. This amount of rules is very beneficial for a young Agile team. They ensure that your process will improve. Actually, this is what we have done for over six months. And we must say that things have improved a lot.

However, we also felt a drawback. Scrum resulted in some limits for us that were very difficult to overpass – like dealing with urgent support tasks for our clients. Another aspect is that Scrum asks for a drastic change of rules and approaches, which not all the companies and individuals can handle easily. For example, Scrum specifies that while working on a Sprint Goal, nobody (except the Product Owner) can interfere with the team. So if any functionality or team change is needed, it is highly recommended to wait for the Sprint end. If your current working culture allows interfering with the development team at any time, like changing the developer’s task at any time, then this is bad news for you. This should not happen anymore.

Kanban, on the other hand, gives more freedom to your approaches. This liberty, in certain aspects, is very beneficial for a responsible and adult team, while an inexperienced Agile team can face a lot of impediments in their way to agility because of it. In fact, Kanban is a methodology that can easily be applied to other processes, even to Scrum at a certain level. And this is exactly what we have done.

"Scrumban" is what we call our methodology. We have analyzed what benefits from both methodologies we can use in order to improve our practices and defines our own rules. We opted for a "Kanbanish" approach that helps us with both development and support work for our clients, but we have included a lot of the Scrum elements that we felt that were beneficial for us – like daily meetings, a PO responsible for the Product backlog, scheduled reviews, and many others.

Overall, this is what being Agile means. It is all about building excellent products that make the business happy by using practices and approaches that make the developers happy. It is about reacting and adapting to changes in order to continuously improve.