Agile – When to? and How to?

So, lets say as an organisation it is decided to go agile. But which method of agile you should be using?

First of all, there is a reason why you are willing to go for an agile methodology. I suggest you write down those reasons first. Switching to agile can be seen easy, but implementing the processes required can be problematic if an organisation happen to have certain behaviours / habits.

Writing down your reasons for switching to agile, can guide you along the way.

Alright, now you have your reasons in hand. You know your biggest issues. Is any of them listed below?

  • Lack of visibility (what is being developed, who is developing what?)
  • Lack of communication (is your team aware of what is going on?)
  • Lack of ownership (If you hear someone saying “That is not my thing to do” then do you know whose?)
  • Lack of strategy (Where is your ship headed? Are you going where wind takes you?)

I am not saying agile is an answer to that. I actually believe any company with a good mindset does not even need agile methodologies, but since they provide useful scenarios, practicing those methodologies can increase productivity.

So, now what do we have in hand? We have Kanban, Scrum, Scrumbun, Lean etc.

Kanban and Scrum are pretty popular. Scrumban as name implies, a mixture of these 2.

Which one to choose?

I suggest Kanban when your team have a good communication flow between members. When there is a high maintenance going on and there are tons of urgent things to be taken care of. The whole idea of Kanban is to have a single board where the flow is precisely defined and each task can be tracked with just one look. Kanban does not need set of roles or ceremonies. You can have them but they are not required.

The biggest issue with Kanban in my opinion is that it relies too much on the autonomy / communication of the production team. If they are not well orchestrated, Kanban will not work. But if you happen to find the harmony, well it works pretty well. It is suited for mature teams.

Scrum can be summarised as a methodology that has roles and time-boxed events. You again have a board, but this times instead of focusing on a flow, you focus on events. Teams run sprints in which they try to deliver what they have committed. After each sprint it is necessary to deliver a working increment. The roles (development team, scrum master, product owner) makes sure everyone knows their responsibilities and their area of operation is clear. Communication still is expected to be clear. If you are starting a new project, scrum can be a good option.

Scrumban, well lets easily say it is a mixture of Scrum and Kanban. You have your board, you have your flows and now you also have your roles. You can give estimations if you like, you can have ceremonies. The idea is, oh we have a cool flow, but we want to make some role definitions that will help us to move things easier. By the way, lets meet once in a while or whenever is necessary and talk about stuff. We dont need to run sprints, but we need commitments. If you are working on a legacy project, fixing and adding things at the same time and you also have to make commitments, Scrumban can help.

Go questions? Drop me a comment.



Leave a Reply

Your email address will not be published. Required fields are marked *