Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Different paths for different styles of work. In my experience you have teams who can have a pulse with the incoming work, more often development, so being able to limit the disruption makes scrum easier to work with.

On the other hand, if you have a team who is going to be working on more "at the time" needs, Kanban lets the disruption get absorbed in real time while the team gets to focus on the WIP pipe. I've seen it used most successfully in teams that have smaller, more isolated tasks to deliver that are able to be isolated to the scope of the team. Intra-team coordination with Kanban is more difficult than scrum (but doable) as long as the working model is understood on all sides.

My preference is to operate more in a Kanban model but when working with other groups who operate with scrum you need to tweak things to integrate.

It also isn't a system that, once picked, you're stuck with. I had a team who did scrum for a few weeks, twice a year during organizational planning so we are kept in rhythm with the rest of the company. Once we had a good enough idea in how we were going to move forward, we switched to kanban to manage our work until the next Co. planning cycle.

There's no true Scotsman when it comes to planning and agile and you'll never find a definitive correct answer that can be broadly adopted. Being open to change to make it work with your org and the people you work with is going to get you closer than blindly following any strict dogma.

// ramble



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: