Live data from Hacker News

You don't need Scrum, you just need to do Kanban right (2022)

lucasfcosta.com

81–90 of 341 posts

Re: You don't need Scrum, you just need to do Kanban right (2022)

#81
post #13

I am probably missing something but is kanban even the correct metaphor for creative work(like software development). Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?

It's about limiting the amount stuff under construction.

You got a list of shit that needs to get done. You have 5 people in the team.

On the Kanban board you can see how long each item has been in each column and you can see who's working on it.

You can also limit the amount of items each person can be working on simultaneously. It should be exactly one or you're multitasking, which isn't good for anything.

You have a single task you work on, when it's done you move it forward. If you get stuck you move it backward and comment on it why it's stuck and pick a new one.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#82

I've heard over and over from managers that scrum is better at anticipating delivery dates. Even when the dates are consistently missed. They'd rather slow teams down with process so they can have a date to give their stakeholders, regardless of its accuracy.

You can calculate the team velocity pretty easily in Scrum (amount of story points completed per sprint) and from that you can estimate what gets done in what time.

BUT it needs the exact same team to be together on the same codebase. You add or remove people, the velocity changes. You change projects, velocity changes.

People also need to be honest when estimating tasks, don't be a 10x cowboy and say something is a half-day task when you know it'll take two days.

It's always better to pick too few tasks for a sprint than it is to take too many. You can always grab more stuff off the project backlog if the sprint backlog runs out mid-sprint.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#85
The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three.

Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint.

Kanban specifies fixed scope and quality, letting time be the floating factor for each task.

Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way.

There are some applications that Scrum does fit better than Kanban, notably anything tied to a real world calendar, say a scheduled live event or a school year or holiday or other seasonal concern. But yes, most businesses don't need to be time-boxed with Scrum anywhere near as much as they think they do, particularly given how much of that time is always consumed by organizational friction around the time-boxing negotiations.

(What happens if you do try to constrain and specify all three? We call that a death march. Actually, time invisibly flexes as workers cram in effort at a higher pace, until they burn out and then you're back to quality implicitly or time explicitly giving way unless you reduce scope.)

Re: You don't need Scrum, you just need to do Kanban right (2022)

#86
post #53

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their e…

For the purposes of understanding the way people act, it is important to focus on what they believe to be the truth, not what the truth is.

Software development is incredibly opaque by default (heck, even we don't know how far along we are, most of the time) so anything that improves that will be perceived as improved productivity.

But even if it's not, sometimes progress reporting (however rough) is needed to synchronise with other parts of the organisation. It just needs to be put into a form that is useful (e.g. for agile projects "percent of plan delivered" is not a useful metric) and how it's going to be used should be explained to those producing it. Heck, optimal is if the people making software and the people they need to coordinate with can get together and jointly agree on what type of reporting is actually meaningful for both parties.

Almost always, we're discussing vanity metrics though.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#87
post #53

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their e…

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#88

The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…

This is a good explanation about differences between the three

Re: You don't need Scrum, you just need to do Kanban right (2022)

#89

I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation. A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example: > When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.…

"This works really well when the engineers themselves have all the knowledge+ability to tackle the problem."

This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#90

Earlier quoted context omitted.

Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team d…

> It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a sin…

> This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.

It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.

Post reply on HN