Agile methodologies, in some or the other form, have been around for close to three decades now. They have been immensely popular for software development across the world for a better part of a decade now. But there still are people who do not want this change. There still are pockets of resistance towards Agile and Agile Principles. There seem to be so many reasons why somehow Agile does not seem to be ‘right’ for them. Some are valid, others not so much.
Over the years, I have seen a lot of misconceptions people had about agile people which prevented them from transitioning to agile. In this post I wanted to dispel some of them. This may not be an exhaustive list but here are some of the most prominent ones. I will probably write a sequel to this post as and when I am able to find more ‘hurdles’ to Agile and how to tackle them.
So without much ado let us see how to tackle the first few ‘hurdles’.
‘I don’t want to restrict a well performing team with unnecessary ‘process’.’
No one likes unnecessary and heavyweight ceremonious process that exist only because someone mandated it. And none of the Agile processes are exceptions. Agile only expects a few specific conditions to be met.
- Each iteration should finish with added value for the customer.
- Software gets continuously validated.
- Stakeholders should be actively involved.
- Self organising teams.
- Continuous improvement.
Agile doesn’t mandate how you achieve this, nor advocate a standard. If you are able to achieve these then you are agile. So there is no extensive and unnecessary ‘process’, there is no bureaucracy and no process that no one understands. Teams only work on those ‘process-things’ that satisfy the above 5 conditions. Everything else is extra.
‘A daily status meeting: Oh! Its too stressful’
If you or your company see it as a status meeting, then you are doing Agile wrong. The point of this meeting is that everyone in your team knows what everyone else is doing, with the specific intent of making sure that the goals for that iteration (Sprint if you follow Scrum) is complete. It can serve as a status meeting for management, but if that is all that is happening then it is wrong. The point of a daily short meet is to ensure that everyone in the team knows the progress, can ask help or be of help if possible and to make course corrections if it seems they wont meet the goals for that iterations. And most importantly convey it as early as possible if it seems that the goals for the sprint will be missed.
All Agile methodologies accept failures so long as we learn from them. In fact the Agile way is to fail fast, fail early when too much effort, time and money hasn’t yet been committed to the project. So if you look at it as a status meeting, then you are doing it wrong. For a developer it is a forum where developers tell what they did, what they plan to do and most important try to predict impediments so that the scrum master can work on clearing them as soon as possible. Also management need not be present in that meeting. If they are, then they need to be only listeners and provide input when asked for. The scrum master can brief the management in another meeting.
‘Agile gives license to throw away all discipline’
This misconception hurts both ways. It scares away people who want a disciplined execution of the project and it attracts those who think discipline is a chore.
The truth is that agile expects a lot of discipline from developers. It just doesn’t expect the processes and ceremonies to be imposed by the management above. On the contrary, it expects the team to be adults and evolve a process that works for them and also helps them meet all agile and project goals. Discipline is not stressed but it is implicit, and without discipline you can’t hope to succeed. The only difference is that the team follows rules and processes that make sense to them and not some company diktat that they comply with without understanding its purpose.
‘Agile is for short-term projects’
It is easy to see why there could be a misconception like this. The dev team usually focuses only on the goals for that particular iteration. So an outside observer might see a very short-termist outlook. And hence the view that this probably wont work for long term projects. And unfortunately many teams do work in this way, hacking up the code just so that the demo at the end of the iteration can be done. If a team works that way, then they are not agile.
Agile does say that you concentrate on just enough architecture and design to make sure that your sprint goals get met. But nothing stops you from having architectural issues and bugs in your sprint backlog. Usually if your architecture and design are not up to the mark, there definitely will be bugs. Nothing stops you from revisiting design once a feature is done. In fact you cant be truly agile without being constant, ongoing, small doses of refactoring. When the product owner is pushing features to the sprint backlog, the team also should be able to push architecture and bugs to the sprint backlog and then prune the backlog to make sure that only those many items that can be finished in the iteration remain. This way you can be truly agile and work on a long term project.
There are many more hurdles to Agile, that I will discuss in subsequent posts. For now I am leaving you with these. Do share your feedback in the comments. And don’t forget to subscribe to BeingNimble to get the latest posts right in your inbox.
References
- A bit of an explanation about the conditions for agility here.
Being Nimble 