You don't need Scrum, you just need to do Kanban right (2022)
161–170 of 341 posts
Re: You don't need Scrum, you just need to do Kanban right (2022)
#162Earlier quoted context omitted.
I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?
nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points. By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is t…
Re: You don't need Scrum, you just need to do Kanban right (2022)
#163It is specifically designed for interfacing with project-external stakeholders.
It works well for “project teams” in a large org for whom the project isn’t the primary business focus. e.g. an internal tool to assist with problem X, or a development project for an external entity.
There is no other use case for which scrum is a good fit - and it’s those mismatched experiences that always result in scrum hate.
I think people just got caught up in the cool name and the certifications and blah.
Stop using scrum for the wrong thing!
Re: You don't need Scrum, you just need to do Kanban right (2022)
#164I 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.…
> But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback. But how does Scrum help out here?
Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization.
This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way".
I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#165Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#166Earlier quoted context omitted.
I've seen Kanban work well on smaller scales, and Scrum work well on larger scales. I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me. I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not. It's a case by case kind…
The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency. We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.
Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all.
The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?"
If one month counts as a small amount of time and money for your organisation, then you're doing it right!
Re: You don't need Scrum, you just need to do Kanban right (2022)
#167People trying to shoehorn scrum into their startup is the problem - not scrum itself It is specifically designed for interfacing with project-external stakeholders. It works well for “project teams” in a large org for whom the project isn’t the primary business focus. e.g. an internal tool to assist with problem X, or a development project for an external entity. There is no other use case for which scrum is a good f…
Re: You don't need Scrum, you just need to do Kanban right (2022)
#168Re: You don't need Scrum, you just need to do Kanban right (2022)
#169Scrum is meant to protect the team from changing requirements mid-work and it's a good way to work when you have a "client" that requires "features" to a product. There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client/pr…
Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum.
Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protection might be useful.
All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".