Published March 16, 2016 · 5 min read

Before going deep in the subject, I would like to emphasize that this post is completely personal. You miBefore going deep into the subject, I would like to emphasize that this post is completely personal and based purely on my own experience. You might agree or disagree, and that’s perfectly fine. You might even have really good experiences applying these agile frameworks in your own teams.

Nevertheless, personally, I donʼt think they provide much value in most real-world settings. Over time, I’ve seen how the frameworks often grow heavier than the problems they try to solve. What begins as a philosophy of agility sometimes ends up buried under ceremonies, roles, and rigid checklists.

In this post, I want to share why I feel that way and what simpler, more effective approaches have worked better in my experience.

Agile software development cycle

Agile Software Development

Agile Manifesto vs. Frameworks

First things first, Kanban, Scrum aren't equal to agile manifesto. They are agile software development frameworks. The Agile Manifesto (http://agilemanifesto.org/) is simple, clean, and doesn't enforce any methods. Letʼs remember the Agile Manifesto.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

As you can see, itʼs up to you how to apply the Agile Manifesto because itʼs open-ended. The manifesto follows the KISS (Keep It Simple, Stupid) principle. However, frameworks derived from agile principles donʼt always 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.

Alternatives That Follow KISS

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.

Task board example

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 visualize.

Example:

• Customer #1: 2, Customer #2: 3, Customer #3: 90
• Customer #3 wants Task #2
• Customer #1 and #2 want Task #1
• Task #1 takes 2 days, Task #2 takes 3 days

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 visualizing status of software that's worked on. Anything more than this stuff can be specific to teams or projects.