Workflow Platform for all kinds of business process and approvals
As competition for better products increases in the global economy, project managers have many new considerations to keep their product competitive and relevant. One of the biggest choices in selecting the right project development models (Scrum and Kanban) inspired by an equally famous and successful set of values and principles system (Agile Methodology).
Contrary to what most people believe, Agile is actually not a methodology. A project management methodology typically gives you a unique set of procedures and ‘methods’ to follow, which is not the case with Agile.
Agile is a set of beliefs, values, and principles that can be used by teams to make decisions with greater confidence. By following these values and principles, a team can hope to achieve ‘agility’ in its operations.
This is a surprisingly flexible alternative as it doesn’t do the actual decision making for you, rather it gives you a set of core beliefs and principles which can help you develop better strategies for project management. Agile proposes a set of values that are to be preferred over other values in order to execute projects more efficiently.
Consider a new project where the discussion is about how to get requirements from the business owner. The suggested approach is to get the owner to write down all the requirements before project initiation and sign them off.
A team following agile methodology here would take this suggestion with a pinch of salt and see it as being inconsistent with their policy of valuing customer collaboration over contract negotiation. They will try to find ways to make this decision in a way that is consistent with Agile values.
However, Agile also comes with some downsides. Since it puts a little emphasis on necessary designing and documentation, the project can easily lose direction if the customer representative is not completely clear about the final deliverables they want.
Normally in Scrum project management, there are three main parties.
Part of making a process Agile is that value, benefit, and features are delivered to the end-users in small increments and their feedback is fed back into the process. It’s the project owner’s job to gather the input from the end-users and organize it in the form of a prioritized list of Features and User Stories called the Product Backlog.
The key difference in the Kanban vs Scrum debate happens is the relationship between the customer and the product backlog.
Scrum methodology teams divide their tasks for a time period of 2 weeks, which is technically referred to as a sprint. A scrum sprint planning meeting is conducted before every sprint where the development team commits to working on certain high priority items during the sprint.
At the end of the sprint, the product is ready for release, blockers are identified and incomplete work is sent to the product backlog.
Unlike Scrum, Kanban methodology is a continuous process. A Kanban board generally contains three columns:
The items get ‘pulled’ from the first column to the next columns and thus a workflow is established. Kanban too has daily standup meetings like Scrum. At near project completion, demos are made for stakeholders and meetings are held for discussions about project retrospect.
Scrum is advantageous with its system of a product backlog, its flexibility in deciding the amount of work that needs to be done in a sprint and the variety of tasks it provides the developers to work with. Scrum has a set of fundamental rules called the five values of scrum which can be implemented in daily work life for improved productivity. The downside is that a dedicated resource in the form of a scrum master is always required and the developers have little influence on shaping up the product.
On the other hand, the Kanban system delivers flexibility, reduces wasted time and work and gives a continuous product flow. The cons are that there’s no time frame associated with particular tasks which makes delays a possibility. Furthermore, often teams make the Kanban board overcrowded and complex which causes issues in the process.
Scrumban is a hybrid methodology that combines the best principles of both Scrum and Kanban. It was originally designed as a way to transition to Kanban from Scrum.
Scrumban combines the prescriptive nature of Scrum like decision making and prioritizing and the process improvement of Kanban to deliver continuous outputs while keeping the processes efficient. It uses the pull system, limits the work-in-progress items, and visualizes the flow of work, borrowing these ideals from the Kanban philosophy.
Scrumban saves time as the sprint planning is done without. Planning meetings happen on an on-demand basis and only when WIP items fall below a threshold. It also helps compartmentalize large projects and eliminate bottlenecks.
While the advantages are many, it does come with a few deficits. It becomes difficult to monitor and track the project progress as there are no daily stand-up meetings. While development teams can use it, it’s best for maintenance projects, help-desks, and event-driven work.
It’s important to realize that it’s the philosophy and the set of values and principles which are more important than the actual tools. Scrum and Kanban are both robust tool systems that try to make implementing the agile philosophy easier for you by using project management software. So, it’s really not correct to compare scrum vs kanban.
Generally, if the emphasis should lie on planning and progress, then Scrum is a better candidate while if the goal is better workflow and throughput, then Kanban might serve as a good starting point.