Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasfcosta.com

Post reply on HN
Print view View original

191–200 of 341 posts

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

#191

Post by Closi »

jdkoeck wrote: post #117
klik99 wrote: post #48

Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets. However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more…

No idea what you mean with outcomes vs means/tasks. Just put outcomes as cards in your Kanban board, they don’t have to be tasks.

I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint.

Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.

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

#192

Post by nvarsj »

ShadowBanThis01 wrote: post #189

Too bad the article doesn’t say what Kanban is.

Indeed. You can even argue that scrum is one implementation of Kanban.

Kanban afaik just describes having a swim lane task board. The process for managing that board is left as an exercise to the reader.

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

#193

Post by ShadowBanThis01 »

haxiel wrote: post #34

Background reading: Defining Kanban and Scrum (since the author skips over it in the article). https://www.atlassian.com/agile/kanban/kanban-vs-scrum

Thanks. I found it annoying that the author never says what kanban is. By leading the title with scrum, you can argue that it’s for those familiar with it. But then the article neglects to describe the alternative it claims is better.

It’s akin to saying, “You don’t need yoga; just do twiddlebop right,” and never saying what twiddlebop is.

It’s also rife with meaningless declarations, like the one about “pushing decisions to the edge of the team.” WTF is that supposed to mean?

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

#194

Post by theshrike79 »

drvd wrote: post #169
theshrike79 wrote: post #75

Scrum 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…

> Scrum is meant to protect the team from changing requirements mid-work 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 protect…

Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work.

Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week".

This is why in Agile we have the Scrum Master who fields all requests like that and tells Marketdrone A to fight Marketdrone B on whose task is more important, because team only has enough time to complete either task on the next sprint. Every time someone tries to interfere with the team's work they firmly direct the person to the SM. In a few actual cases the team's SM has physically removed the over-eager middle manager out of the team's space with their "few quick requests and improvements".

I'd really want to know what kind of tasks can't be completed in two weeks in your opinion.

The tasks in a sprint aren't "build a house from scratch" -level, you split them until they're in manageable chunks of time. In a single sprint you might have the task of clearing the plot from any trees and laying down the markers for the house's base.

Then the client comes in and approves the direction or asks you to make the bathroom a bit bigger or move the house 5 meters to the east - which is still easy because the "house" is just stakes in the ground with string connecting them.

And again you pick 2 weeks of work you know your team can finish and the client checks that everything looks good. etc etc.

It really isn't complicated. I think the majority of HN has only been subjected to cargo-cult Agile or some kind of Agile-ish system where you just use the terms, but none of the actual processes.

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

#195

Post by Closi »

ajmurmann wrote: post #93
lmm wrote: post #73

Earlier quoted context omitted.

> As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort. However what they do reasonably need is the ability to priori…

It depends what you are working on, how you ship and how three rest of the company works. I work on Enterprise software that's not SaaS. We ship every 9-12 months. If we do it more frequently it just annoys our slow-moving costumers and increases our support burden because there are now more versions in support that might need patches. Our sales and marketing teams need to know when we ship. Sometimes costumers mighy…

Yep, or if you are working on a project to build a control system for a new factory which is going live in 18 months, it's pretty reasonable for your management team to want to know that you have confidence you can build the control system within a year.

If not, they will probably want to cut the scope or put other risk mitigation in place.

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

#197

Post by jon-wood »

Gareth321 wrote: post #182
dilyevsky wrote: post #105

Earlier quoted context omitted.

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically

> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected deliv…

> We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.

Now where have I heard that before? Ahh yes, at this little website: https://agilemanifesto.org/

My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push back on exactly that.

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

#198

Post by Marazan »

Heavy assumption in the comments that sprints "are" 2 weeks.

I've found scrum works best with 1 week sprints. It forces ceremonies to be short.

But at thr end of the day the only important parts of Scrum are ensuring the standups are run ruthlessly short, no fat, and that the Retro produces actions that are actually done.

Because if you are running proper retros after 6 months "your" Scrum won't look like anyone else's Scrum as it will be customised to your work and team.

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

#199

Post by ResearchCode »

theshrike79 wrote: post #188
ResearchCode wrote: post #178

Earlier quoted context omitted.

Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.

Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing…

I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term.

Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.

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

#200

Post by EliRivers »

marginalia_nu wrote: post #150
dilyevsky wrote: post #105

Earlier quoted context omitted.

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically

I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe). My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality. Th…

I've had similar experiences with waterfall; projects running on time, over multiple years, on which the end users never reported so much as a single bug.

As you say, it demands really good requirements, which can only come from high-quality customers. Most customers are not high quality. They are low quality. They are bad. They don't know what they want and don't know how to express themselves. As you suggest, a really good requirements person can tease these details out of them, but in my experience a great many companies don't even realise how bad and incompetent a lot of their own customers are.

Post reply on HN