Scrum, Kanban, or just Agile

Before going deep in the subject, I would like to emphasise that this post is completely personal. You might agree or disagree. It’s up to you. You might even have really good experiences applying these agile frameworks. Nevertheless, personally, I don’t think they provide much value and let me explain why.

First things first, Kanban, Scrum aren’t equal to agile manifesto. They are agile software development frameworks. They suggests methodologies to apply agile principles. Agile manifesto is simple, clean and doesn’t enforce any methods. Let’s remember agile manifesto.

As you can see, it’s up to you to how to apply agile manifesto because it’s open ended. Agile manifesto follows KISS principle; however, frameworks derived from agile principles don’t follow KISS. In my experience, they can make your life even more complicated than it was before. They introduce new roles, new methods, and new discussions. From now on, I’ll go through examples to highlight why I don’t see much value in applying these frameworks.

Example #1: Planning Poker

Assumption: Estimates done through days to complete a task.

• Why somebody else estimates my task?
  • Amount of time spent for a task is personal
    • One might lack some technical/domain ability
    • People works different number of hours
    • Wrong estimates can decrease one’s morale
  • Team can’t know every piece of software produced
• Estimates never include disasters
  • Stop the world and fix bugs occur occasionally
  • Refactorings

So, estimating task completion as a group doesn’t provide much value and most probably is great loss of time. A planning poker might probably take half of the day but you can deliver a small feature or a bug at that time span. I’ll admit that planning poker is a fun activity and can be useful for those who joined the team recently.

Example #2: Meetings

A typical scrum team has between five and nine people. In an ideal world where everyone works for the same project, scrum team makes sense. Nonetheless, that’s not the case for most of the teams I’ve seen. Hence, team meetings becomes problematic because there is no focus.

• Teams are expected to carry more than one project and most probably many projects.
  • Status updates from different projects doesn’t catch attention
  • One project can dominate the others
  • Roles, come on! They become useless in one man projects

On the other hand, meetings can provide information exchange and general view of the team. They are needed but probably not everyday. Most importantly, meetings focussed on individual projects are much more effective.

Example #3: Roles

Roles are important part of agile frameworks and they aren’t easy to learn and practice. Furthermore, they are strict so they restrict freedom of developers.

• Learning and applying roles are costly
  • Learning each role would take at least a day
  • Deciding on whose’s who can be a challenge
  • Companies pay a lot to trainers
  • You don’t get certified for every role even after a training
• Loss of Freedom
  • Direct interaction to customer is lost since we have product owner
  • Scrum master can be bossy

Clear roles and structure might be good for some organisations and might be a hindrance for others.

I’ve just gone over 3 examples; however, one might come up with many others. I think it’s worth to discuss an alternative to these frameworks. Thus, I’ll suggest two simple methods which you might be familiar already. I believe these two methods follow KISS principle.

Method #1: Task Board

A board to visualise what’s going on currently. It might be a software tool or it might be just physical post-its. There might be estimates or not on individual tasks.

Method #2: Task Priority

A task priority is weighted sum of customers becoming happy/unhappy divided by number of days to spend on. I’ll give an example to visualise.

Customer#1: 2, Customer#2:3, Customer#3:90

Task#1 takes 2 days and Task#2 takes 3 days

Customer#3 wants Task#2

Customer#1 and Customer#2 want Task#1

Priority for Task#1 =  (2+3)/2 = 2.5

Priority for Task#2 = 90/3 = 30

So, we first work on Task#2 and than Task#1. Note that, bugs probably has more weight because fixing broken software is more important.

That’s it. Nothing more. These two methods don’t tell you or enforce you to conform certain rules. They are just focussed on delivering value and visualising status of software that’s worked on. Anything more than this stuff can be specific to teams or projects.