Knowing which agile methodology to use is something that can be a sticking point for many in delivery. Which methodology is right for your project? Do you use agile? If so, do you use traditional agile, safe agile, scrum, or kanban? There are so many options.
How do you address the seven wastes in software development? What if your project is more suited to Prince II or is heavily dependent on ITIL? Many people believe Extreme Programming (XP) to be closer to the original ideas of the agile manifesto authors. The choice can be endless. This article explores the differences between traditional agile, scrum, and Kanban.
All agile processes are centralized around four core values. These are:
The key things to think about when deciding which form of agile to use are; How responsive do you need to be? How much will your product scope change and evolve in a short period of time? How strong is your development team?
If you are a purist when it comes to agile you will be more comfortable with the structure which delivers 4ish week sprints, User Stories, Story Points, Stakeholder demos, and so forth. Whilst other flavors of agile use some of these principles, the purist form of agile is most suited to engineering rather than product value and outcomes. It is nimbler than Waterfall but is held back by a lot of process governance rather than being more outcomes-focused – as some would say there is more red tape.
Azure DevOps provides a standardised way of running Agile to help you work plan your iterations. The options provided to manage the requirements are a backlog view which hosts requirements at an Epic, Feature, User Story and Task level along with a sprint board to host the planned User Stories for any sprint.
Let's look a bit deeper. What does Agile do for you at its core:
It’s a great way to transition from waterfall business operations into a new way of working. Given the process domination of Waterfall and Prince II styles of project management, Agile breaths life into being product focused.
If you want high performing teams who take responsibility and work as a cross-functional unit look elsewhere. Agile purity can get you there but the journey is much longer. Delivering product value continually requires the ability to refine and develop, refine and develop in short bursts. Breaking free from the red tape of agile purity can release creativity and autonomy in your teams resulting in better outcomes.
Scrum is designed for product owners that want to work closely with cross functional teams, running a prioritised backlog for delivery.
Azure DevOps provides a standardised way of running Scrum to help you work out your requirements. The options provided to manage the requirements are a backlog view which hosts requirements at an Epic, Feature, PBI and Task level along with a sprint board to host the planned PBI’s for any sprint.
This type of methodology is great for creating new products or working in disruptive industries where the value being delivered is evolving in a niche market. Its also good where you have a strong development team who support the product owner in defining the production solutions.
Scrum increases a teams accountability. Scrum has more transparency and visibility than any other methodology, and easily accommodates changing requirements.
Scrum lends itself to high performing teams that excels when there is a high level of domain experience. Because of this scrum also works well when there is commitment and dedication from its team members.
Having a less experienced scrum master or delivery manager in a scrum team can be detrimental to the teams output as can poorly defined tasks.
Kanban is an easy-to-use methodology, originally developed by Toyota for their manufacturing line, Kanban managed work through a simple work-in-progress (WIP) limit on a swim-lane board – Ready, In progress, Done.
Azure DevOps provides a standardised way of running Kanban with a board view of your backlog. You can work to help you work out your requirements. Choose to work at any level such as Epic, Feature, PBI / User Story or Task
When you have continually changing priorities Kanban can be an excellent choice as it is very flexible and reduces ‘waste’ in time you may get in other methods.
Kanban reduces the delivery cycle and is easy to understand – one in one out so to speak
Because Kanban is priority driving not time driving you can end up with work that goes on and on if there is a lull in priorities.
Kanban’s most focal point is the board which must be continually updated – an outdated board leads to confusion and lack of transparency.
Choosing the right way to do delivery has a fundamental effect on the success of your project. When you hire the right people with the right experience these types of decisions are simple due to the value those people bring to your organization. Proarch can help so why not reach out and let us support you in your product delivery today?
If you'd like to understand more about how we do product engineering at ProArch you can here.