Live data from Hacker News

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

lucasfcosta.com

201–210 of 341 posts

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

#201

Earlier quoted context omitted.

Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.

> business also needs to accept that there are limits to the amount of predictability you can achieve in software development Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.

It’s sadly mostly a sign that they don’t understand it. Most scrum these days is bastardized.

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

#202
post #8

Is “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.

"kanban" is all about maximizing flow of completed tasks, and minimizing/limiting work in progress . Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on. If you have 5 workers and 15 tasks in progress, 10 of those tasks won't…

So if I follow well, the interest is in having all different types of 'blocking stages' in the pipeline so that you can identify the points that slow down your process. With the right tool, and provided the tasks are accurately tracked, you get good statistics pointing to where you should optimize the workflow.

However, it's not so simple to read. In some cases tasks were blocked because of a superficial or nonexistent analysis, which required to get more information. Which is a clear break of the flow, since it has to be paused for the time before the meeting can happen. But sometimes, the analysis can be fairly bad and very time-consuming on the other department, making the broken flow more efficient than the flowy one if you account for the whole team and not only developer time.

Which seems to me that it's a good idea to optimize for flow only after you have enough consistency in the process, but still a powerful tool.

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

#203
post #53

Earlier quoted context omitted.

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…

I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that y…

The problem is nothing comes out of it. We run retros and there are action items and they go into a black hole.

The higher ups do it to follow the process and not to fix the actual problems.

It gets tiring after a while of time wasting.

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

#204
post #162

Earlier quoted context omitted.

Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!

The main point of points is that they are not supposed to be equivalent to x amount of time. They're supposed to represent a measure of complexity. How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on. They're then used to see how many issues will fit in a sprint, which is a mea…

That’s the theory but it doesn’t help managers so they still convert it back to time somehow.

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

#205

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…

As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at…

You make it all sound like a factory and blame developers for going rogue.

That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided.

If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.

I’d argue alignment is useless as most of the time developers are told to implement useless features. Perhaps with some guidance and direction what the developers come up with is better than product.

It’s sad but product is like a theory machine that’s often impractical.

So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year? Even if they do go off for a few months on their own it’s more than worth it.

The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.

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

#206

Earlier quoted context omitted.

Most companies have already hired the contractor though so this little dance is just pointlessness that kills motivation and velocity.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

You won't gain that understanding until you actually complete both of those projects.

Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques (not the things that pass as "project management" in software companies).

For example, even an inexperienced carpenter, asked to install a door system they haven't seen before, will be able to do it two or three times to get a feel and work the kinks out, and then when they're hired to install it in 300 flats of a new apartment complex, they'll be able to give you an accurate estimate of time and effort required.

With software, almost universally, your project is meaningfully unique, and your workers have never worked on something very similar before. The sources of variability are endless - project-unique challenges ahead, programmers never doing that particular component in that particular combination of languages, libraries and frameworks, in their specific versions, programmers and PMs never working in that specific domain before, etc. - and that's before you add stakeholders changing their requirements every other week.

The understanding one needs to have first is that the software project they're holding a stake in is typically best thought of as R&D effort.

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

#207

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…

> Of course, the counter to that is that we're not doing scrum right. That’s almost always the excuse in my experience. It’s not that it doesn’t work, it’s just no one has ever done it correctly.

It’s not that no 1 has done it correctly. It’s that no 1 wants to even do scrum. Most management do pretend scrum. It’s like hype driven development. You just get on the train without caring where it goes.

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

#208
post #169

Earlier quoted context omitted.

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

> Yes, you need the protection.

You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right.

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

#209
post #53

Earlier quoted context omitted.

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…

I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.

But isn't the problem exactly that, that oftentimes we cannot know in advance how long it will take to implement X?

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

#210

Earlier quoted context omitted.

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

The task of the Scrum Master is to make themselves redundant. They just make sure the team follows the structure they agreed on + runs interference for external issues.

After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.

Post reply on HN