The author of the article argues that in practice people put too much emphasis on the process of Scrum and delivering within the sprint and having your task marked as 'done' limiting than on quality. He feels that Kanban, which does not have timeboxed sprints, story estimations, or commitments, is better than Scrum and that Scrum is dead. I disagree, and I think that it really depends on your team and project on how well Scrum works. In my past internships I have used Scrum, and I found it very helpful. It helps you pace yourself, set goals, see what others are working on, and get the help you need if you run into any blocks.Unlike what is mentioned in the article, I have not experienced team members or myself rushing to deliver everything on the last day of the sprint to avoid carry overs. In my experience there can be carry overs for a number of reasons like unexpected bugs, people not reviewing pull requests, or the task itself turned out to be larger than anticipated, which can be annoying, but the carry overs were never seen as bad. They were things to learn from. I think Kanban can be useful for long term projects or projects that aim at improving the quality of an old project, but new projects or timed projects need Scrum.
Diana Zhao dz1371 Feb 4, 2022
The article does indeed provide quite some interesting insights as to how Kanban is better than Scrum. After reading this article I realised that Microsoft had been using the Kanban framework when I interned there (or at least a very similar framework), which does prove that Kanban has been becoming more popular. The project I followed was rather short and only went on for less than a month, and during this time, I watched as the developers worked freely at their own pace, delivering whenever something had been done, and reopening previously "done" events when needed. It was very effective and the programmers worked efficiently, and communicated with the client once a week to deliver. I actually personally feel (based on my experience) that Kanban works better for shorter term projects, where deliverables and work are easy enough for the devs to manage between themselves and individually without the need to meet every single day and set sprints that are too long within the entire time frame of the project. Meanwhile, I think Scrum would work better for longer term projects to avoid significant laybacks, and I agree that it would be very effective for new projects where client needs need to be laid out specifically and be delivered on time. I also agree that, depending on the company or the culture of the company, Scrume and Kanban may vary greatly depending on the type of people using each framework.