Ask HN: Scrum Kanban
Has anyone gone from Scrum to Kanban? Or vice versa? How was it? Did productivity increase? Was overhead lower, higher, or about the same? If you ended up switching back, why?
Sincere thanks for sharing your reflections.
3 comments
When I started at my current company 2 years ago we were doing a rigid form of scrum. Over time, I’ve been able to bend that with my teams towards something that works for them and the product they are working on, instead of the other way around. What we ended up with is closer to Kanban; we stopped sprints and sprint planning and replaced it with WIP rules, and pulling work on the board when needed. We refine stories as needed, which means we don’t spend more time in meetings than we absolutely have to to gain alignment.
We've retained things from scrum we deemed useful, like the retrospectives, and some sort of regular alignment with stakeholders.
Altough not part of scrum or kanban, we’ve exposed engineers more to customers, instead of internal stakeholders, which means the solutions we’re making are much closer to what customers actually need vs what a stakeholder thinks they need.
Overal, the feedback from both engineers as well as stakeholders has been very positive, citing less meetings and more time to make an impact, as well as faster time to impact.
I don't see them as opposed to each other but instead choices of different options from a menu of management technique.
In the case of Kanban you are writing well-defined tickets and limiting how many can be in progress at once. It's a common practice in many kinds of systems such as short order restaurants and cafes (e.g. at the cafe for our engineering school the people who take orders also make the food and they don't take your order until the depth of the queue drops)
For Scrum you are adding a bunch of extra options such as:
* regular meetings
* estimation of tickets
* sprints
Really the game is to develop a process that works for your product and your team. About 10 years ago I was working on a product that had an A.I. model in it that took 2 days (mostly unattended) to train if everything went right. We rebuilt the model for each 2 week sprint. I found Scrum's practice of accounting for punchclock time as opposed to calendar time did not work for this project because people would wind up starting the model training too late to have it done for the sprint, which was particularly problematic because early on model training might fail and it might take 2 or 3 attempts to build a model. I pushed for applying PERT charts so we could always start that kind of task early so the sprint could succeed even if we had some trouble with the model. We had a culture of not working on the weekends but actually running a model build over the weekend was a good answer and usually took about 30 min of somebody's time to monitor.
In the dark ages before agile I frequently worked on teams that didn't really know how to build their product. You can easily have a few people working for a year with their IDEs, not thinking it was a problem that it took a new dev 5 days to get their build sorta working, then when it comes time to deploy they could spend anywhere from 2 weeks-6 months to actually make a build you can put in front of customers. Agile teams who don't have a totally broken process have that problems solved because they regularly make a complete build. The typical 2 week cadence of Scrum is faster than many organizations but it can become a source of delays. For instance if you really understand build and deploy a manager could ask for some (truly) tiny change like adding some space above a button and that change could be put in front of customers in 2 hours as opposed to 2 weeks.
In the case of Kanban you are writing well-defined tickets and limiting how many can be in progress at once. It's a common practice in many kinds of systems such as short order restaurants and cafes (e.g. at the cafe for our engineering school the people who take orders also make the food and they don't take your order until the depth of the queue drops)
For Scrum you are adding a bunch of extra options such as:
* regular meetings
* estimation of tickets
* sprints
Really the game is to develop a process that works for your product and your team. About 10 years ago I was working on a product that had an A.I. model in it that took 2 days (mostly unattended) to train if everything went right. We rebuilt the model for each 2 week sprint. I found Scrum's practice of accounting for punchclock time as opposed to calendar time did not work for this project because people would wind up starting the model training too late to have it done for the sprint, which was particularly problematic because early on model training might fail and it might take 2 or 3 attempts to build a model. I pushed for applying PERT charts so we could always start that kind of task early so the sprint could succeed even if we had some trouble with the model. We had a culture of not working on the weekends but actually running a model build over the weekend was a good answer and usually took about 30 min of somebody's time to monitor.
In the dark ages before agile I frequently worked on teams that didn't really know how to build their product. You can easily have a few people working for a year with their IDEs, not thinking it was a problem that it took a new dev 5 days to get their build sorta working, then when it comes time to deploy they could spend anywhere from 2 weeks-6 months to actually make a build you can put in front of customers. Agile teams who don't have a totally broken process have that problems solved because they regularly make a complete build. The typical 2 week cadence of Scrum is faster than many organizations but it can become a source of delays. For instance if you really understand build and deploy a manager could ask for some (truly) tiny change like adding some space above a button and that change could be put in front of customers in 2 hours as opposed to 2 weeks.
Every 'scrum' I have been involved with used a kanban tracker of some form - are they supposed to be "different"?
Kanban is basically "here's a board with tasks, push them to the next column when you're done"
Scrum is a set of recommendations about team structure, project organization, meetings, etc
Scrum is a set of recommendations about team structure, project organization, meetings, etc
Would you say, then, that one is an overall project management method while the other is a way to track progress inside the method?
Kanban is both - it's a name for the board itself, and also a name for a very simplistic project management method that relies on the board and nothing else.
Jira took the board and people started using it while doing Scrum, but you don't have to do Scrum with Jira. BTW the board is kind of new in Jira, it used to be more like Github list of issues before they added it.
Jira took the board and people started using it while doing Scrum, but you don't have to do Scrum with Jira. BTW the board is kind of new in Jira, it used to be more like Github list of issues before they added it.
>BTW the board is kind of new in Jira
Where by "kind of new" you mean, "has existed for over 6 years" ... right?
Jira had the task board / Kanban idea (at the minimum (and, imo, well-implemented) as of early 2018 (first time I saw it))
Where by "kind of new" you mean, "has existed for over 6 years" ... right?
Jira had the task board / Kanban idea (at the minimum (and, imo, well-implemented) as of early 2018 (first time I saw it))