July 19th, 2019 • Project Management
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 is selecting the right project development models (Scrum and Kanban) inspired by an equally famous and successful set of values and principles system (Agile).
Contrary to what most people believe, Agile is actually not a project management methodology. A 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. According to the Agile manifesto, the basic building blocks of the Agile principles are the following:
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 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 project management, there are three main parties. First is a project owner who decides the nature of the project or the type of service/product to be delivered. Second is a team that works towards achieving the project’s deliverables. Finally, there are the end-users who benefit from the project’s outcome.
Part of making a process Agile is that value/benefit/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 Scrum vs. Kanban debate happens in the relationship between the customer and the product backlog.
Scrum teams divide their tasks for a time period of 2 weeks, which is technically referred to as a sprint. A 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 is a continuous process. A Kanban board generally contains three columns. The leftmost column contains project features that are to be worked upon. The column in the middle contains items on which work is in progress and the rightmost column contains the areas on which work is complete. 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. 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, Kanban 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.
It’s important to realize that it’s the philosophy and the set of values and principles which is 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. So, it’s really not correct to compare agile vs 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.