Scrumban – solution that fits our team

Scrumban






If you feel that you have any issues with the methodology approach you have in your company, then most probably you have heard these words already. That is our case as well. At a certain point in time, we felt like we are not facing anymore 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 2 different paths to the overall Agile goal. We think that they are more like 2 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 that ensures that the team follows Agile Scrum principles.
    • Scrum Team – 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 – list of features to implement in current Sprint.
    • Burndown Chart – graphical overview of current Sprint progress.
    • Product – a potential shippable product increment.
  • Activities
    • Sprint – time limited period for implementing a set of features from the Product Backlog.
    • Sprint Planning Meeting – plan, discuss and organize work for the upcoming Sprint.
    • Daily Scrum Meeting – update on current status of the Sprint.
    • Sprint Review – demonstrate the newly implemented functionalities.
    • Retrospective – see what was bad and how to improve.

Essence of Kanban

Kanban is primarily based only on four principles:

  • Visualize work – build a visual model of the workflow (a Kanban board). This makes progress visible, along with bottlenecks, queues and improves a lot the communication.
  • Limit work in progress – reduce 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.
  • Focus on flow – the team is responsible to ensure that tasks pass through the Kanban flow as fast as possible. By analyzing data collected from the flow the team can determine where the bottlenecks are.
  • Continuously improve – the practices should always adapt to the continuously changing requirements.

Our decision

As you see each methodology has its own specifics. 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 benefic for a ‘young’ Agile team. They ensure that just by applying them your process will improve. Actually, this is what we have done for over 6 months. And we must say that things improved a lot. But there is also a drawback that we actually felt. Scrum resulted in some limits for us, which 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 change the developer’s task at any time, then there are 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 benefic 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’ this is how we call our methodology. We have analyzed what benefits from both methodologies can we use in order to improve our practices and defines our own rules. We opted for a ‘Kanbanish’ approach, that can help 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 benefic 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 using practices and approaches that make the developers happy. It is about reacting and adapting to changes in order to continuously improve.

Share this article:

Serghei
Scrum Master