I always think that one tool can’t fit with everything in project management. Scrum vs. Kanban is just a question of the knife vs. chopstick. Kanban is methodology which you can alter as per your requirement while Scrum is a framework and it doesn’t allow tailoring. A product company could have multiple initiatives with the support of existing project/product. In this case, Scrum can’t give all the answer. We need to mix-up the project management technique. In a typical web development company can have the following processes.
1- Web development for new project/existing project
2- Web Design work for a new project
3- Web Support Work (Maintenance work)
I have tried my best to put this all in web development perspective.
|Scrum||Kanban/Lean||Fit For New Website Work?||Fit For Web Support Task?||Fit For UI Design?|
It is a perfect tool for the empirical process where any changes are widespread carried by experience, data, and evidence.
It is a perfect tool where work is coming every time and from everywhere. It is also fit for those work which we need to deliver in one or two days.
|Scrum, since new work could require frequent changes. As the website grows, the frequency of changes will increase. Create registration process could be a new work in this case.||Kanban. Web support task has a repetitive pattern which doesn’t require much coordination in the team. Adding a new page or new user could be web support work.||Kanban, people can’t wait for two weeks to show the design to stakeholder using scrum’s sprint, here you will get the edge using kanban. It will lead you to instant design approval.|
Sprint planning, sprint retrospective, sprint review is part of Scrum.
kanban/lean doesn’t need ceremonies like sprint planning, retrospective.
|Scrum, since coordination and planning are critical here.||Kanban, It can be done using minimum events. Not much planning is required.`||Kanban/lean, stakeholder interaction is frequent in this case.|
|Flexibility, scrum is rigid regarding ceremonies as it is framework.||Very flexible as it is methodology.||Scrum, New work is not always predictive.||Kanban, Web support task is never going to present in sprint review meeting. If we want we can make it time-box.||For this back and forth approval process, it is not advisable to use scrum here.|
|High product quality||Focus on continuous delivery. Removing waste if applicable in the form of various meeting.||Scrum, In the initial stage, we need to validate every requirement by including stakeholder and team in every sprint to know the answer to the question “Are we going in the right direction?||Mostly applicable in maintenance.||Kanban, only stakeholder, and designer required in this case for continuous delivery to fill the design for the upcoming sprint. Quality will maintain using quick review by stakeholder.|
|Time-box is a core of Scrum.||If required, we can add time-box in Kanban/lean.||Scrum, Time-box is mandatory to remove waste.||Kanban, The inclusion of time-box depends on requirement. It can be applicable in any event.||Kanban, The inclusion of time-box depends on requirement. It can be applicable in any event.|
|Less efficient than kanban/lean but Allows the client to change priorities and requirements quickly.||Approx 2 times more productivity than scrum.||Scrum||Kanban/lean||Kanban/lean|
|More rule to follow as it is a framework.||More Adaptive and less rule to follow.||Scrum||Kanban||Kanban|
|Estimation session is required.||Estimation session is not required. The team take the task and start working on it.||Scrum, Estimation session is required to fetch the story into the sprint by team’s past performance.||Estimation is not a requirement for web support task.||If work stays longer than expected due to the blocker in WIP, it will be escalated.|
In a nutshell, we can’t work efficiently in the agile enterprise environment using only one project management methodology. No perfect world is here for everything. It is better to mix up the process for a good result.