Scrum vs Kanban: A Developer’s ‘On the Project’ Comparison
Deadlines are imperative in every organization. Deadlines push us to think how our goals will be accomplished. They help us prioritize work and its duration. In software development, deadlines are essential as food is to living beings. Without deadlines, we can’t be sure about our capabilities and end user expectations. They can be critical to our businesses. 
Different processes, tools, methodologies are used to set deadlines in software development. Some examples include: RUP, XP (Xtreme Programming), Scrum, Kanban, etc. Software teams choose a methodology as per their project requirement. Every process, tool or methodology have their pros and cons. It finally boils down to your project and requirements. Every tool/methodology is complete when used within the defined boundaries. Scrum vs Kanban: On the Project Floor Let’s talk about two process tools I have used – Scrum and Kanban. Certain constraints & guidelines govern them. For example, Scrum constrains you with timeboxed iterations and cross-functional teams. Kanban limits you to use visible boards and restrict your queue size. Using the right tools will help you succeed, but does not guarantee success.
Scrum vs Kanban: Customized Usage We then decided not to limit ourselves to one tool. We tried to mix and match the tools as per our needs! An optimal mixture of both tools was achieved. Sprint planning is still done, so is Scrum poker and estimation. A certain time is reserved for our Kanban board. Kanban issues are tackled as per priority. We also limit WIP. We are thus using both Scrum and Kanban. More importantly, we are now more satisfied with the end results. The good news: We are not failing our sprints anymore. By the end of each sprint we deliver what we had committed to. We do this by tackling blockers/critical and without hampering our complete sprint. There. That’s it. Now you know what I mean. Summary Dear reader, now it’s your time to experiment. Try both methodologies and find out which is best in a certain situation. You may then borrow some points from each tool/methodology and formulate a process tool of your own. This tool could serve your project needs better. For example, if you use Scrum and decide to stop using timeboxed iterations (or any other core aspect of Scrum), then don’t say you’re using Scrum. Scrum is minimalistic enough as it is, if you remove stuff and still call it Scrum then the word will become meaningless and confusing. Call it something like “Scruminspired” or “a subset of Scrum” or how about “Scrumish”?
So, don’t be afraid to be one of the Scrumish guys :). All the best!
(References: Kanban and Scrum making the most of both by Henrik Kniberg and Mattias Skarin)
