Agile is not just a SCRUM. Are you really ready for an agile approach?
Imagine, that you will open the cookbook and you will choose a recipe (project method/technique) based on what you want to cook (project). It would be easy, don’t you think? I think it’s possible to create a set of rules to choose a correct agile methodology. I would say there is more than just a SCRUM.
How do I make a decision to choose a correct agile methodology for project
There are several inputs to consider. For this article, you need to know the basics of agile methodologies. Let’s start.
How many people will be on the project
When you got a project then you will start to analyze the requirements and timeline based on the client’s inputs. From this point, you will know how many developers you will need to achieve a project goal. If there will be only 2 developers then I would go with Kanban. The reason is that the project team is too small to use a SCRUM or XP. A good practice is to have 5-9 developers in one SCRUM team. If you have more developers, then you should split one team into 2 smaller teams. If you have less than 5 developers, use different methodologies like Kanban or ScrumBan.
In my opinion a longer timeline means using more stable, transparent and organized methodology. For example if I know that project will run less than 3 months then I would choose Kanban or ScrumBan, even if there will be 9 developers. But if the project will run longer than 3 months I prefer to lead the project by SCRUM.
This point is tricky. You know as I mentioned in previous points which methodology I would use, then this last point is changing it more. When I got a project what we are going to do from scratch or start-up and it requires weekly or even daily changes in priorities then it doesn’t make sense to me to start a SCRUM. I would go with ScrumBan and later easily switch to SCRUM, when the priorities will be possible to set clearly by product owner for stable sprint period.
If the project has service/maintenance purpose and you have a backlog but even tomorrow morning you can receive new priorities from a client or new bugs to fix, then I would go with Kanban.
At the end
These three points are basics and additionally, you have to take into account if your colleagues (developers) are ready for selected agile methodology. If not, then you need to be careful and teach them basics. Encourage and couch them. Communication and explanation is the most useful strategy here.
Besides colleagues, there is another point you need to take into account also your’s and customer’s company. Both of them need to be aware of the methodology and accept or understand it. Why? This is for another article :)
One more thing, do not hesitate to change methodologies over the projects. It’s your comfort zone to use the same processes and methods as before. Just step out and try something new.
Waterfall was for a long time a good project methodology and now you can see there are numbers of better methodologies that can make your project successful for you and your customer.
We have more interesting articles about project management coming up, stay tuned!