Why (and When) Scrum Doesn't Provide Value

before going deep in the subject, i would like to emphasize 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 the agile manifesto. they are agile software development frameworks. they suggest methodologies to apply agile principles. the agile manifesto is simple, clean and doesn’t enforce any methods. let’s recall the agile manifesto.

as you can see, it’s up to you to how to apply the agile manifesto because it’s open-ended. the manifesto follows the 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 estimate my task?
  • amount of time spent on a task is personal
    • one might lack some technical/domain ability
    • people work 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 is probably a great loss of time. planning poker might take half of the day but you can deliver a small feature or a bug in 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 on the same project, a 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 don'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 who’s who can be a challenge
  • companies pay a lot for training programs
  • you don’t get certified for every role even after training
• loss of freedom
  • direct interaction to the customer is lost since we have a product owner
  • scrum masters 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 with already. i believe these two methods follow the kiss principle.

method #1: task board

a board to visualize what’s currently going on. it might be a software tool or it might be just physical post-its. there might be estimates 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 a task. i’ll give an example to visualize:

• 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 have 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.