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

Scrum disempowers developers

lambdacambridge.com

Post reply on HN
Print view View original

301–310 of 382 posts

Re: Scrum disempowers developers

#301

Post by geezerjay »

s73v3r_ wrote: post #292
geezerjay wrote: post #188

Earlier quoted context omitted.

> You're describing having a well defined goal, setting a critical path, and then regularly updating your progress. What we gray beards used to call "project management". That's not true at all. The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projec…

"The whole point of organizing projects around scrums is precisely that there is no well defined goal nor can one exist. What exists are the client's needs, and those needs do and will change frequently and radically as projects move on." I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices regarding the design.

None of these assumptions hold even in conventional engineering projects. The only reason why waterfall processes is used in conventional engineering projects is that it's so expensive to fix problems arising from these sources of failure that it's perfectly fine to deliver working but inadequate solutions.

Re: Scrum disempowers developers

#302

Post by s73v3r_ »

jmulho wrote: post #203
specialist wrote: post #86

Earlier quoted context omitted.

Paraphrasing: The Agile Methodology is to argue about The Agile Methodology. Source: Certified Scrum Master training. Three times. Still have no idea what these charlatans are talking about.

Which is a higher distinction, Scrum Master, Web Master, or Dungeon Master?

Dungeon Master. They're the only ones that can do something as simple as place an apple on a table, and tear apart your entire team.

Re: Scrum disempowers developers

#303

Post by nradov »

Clubber wrote: post #283
nradov wrote: post #275

Earlier quoted context omitted.

Your full regression test suite needs to be 100% automated and fast enough to execute within a couple days. If you don't have that then you have a bigger problem that goes beyond any particular development methodology. A proper Scrum definition of done requires full test automation for every user story. You can't merge code to the release branch or accept the user story until all the automated tests (unit, functional…

I assume you don't mean unit tests, which should never be a replacement for full regression testing. Ya since that is essentially a deal breaker, I wonder why all the scrum consultants fail to mention that. Automated full regression is very expensive to develop and maintain. I think a lot of people who implement scrum don't realize that they are sacrificing significant levels of testing when they implement it without…

I mean all tests — unit, functional, performance, everything — necessary to verify that a particular product build meets your customer's quality standards. Automated full regression testing is far cheaper than manual testing. If it seems too expensive then you're probably doing it wrong or failing to account for full lifecycle costs.

This is absolutely not a reason to ditch Scrum. In fact Scrum is conducive to good quality practices.

Re: Scrum disempowers developers

#304

Post by vannevar »

some_account wrote: post #259
vannevar wrote: post #143

Earlier quoted context omitted.

I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. How exactly does agile prevent you from talking to your teammates and getting feedback from them?

Team mates are the ones I'm working with all the time. I don't need scrum processes to talk to my team. A good team knows how and when to share information.

A good team knows how and when to share information.

True. Scrum is a floor, not a ceiling. Nothing prevents the team from going above and beyond the daily standup and the sprint review in terms of communication, and I've never been on a team that didn't communicate a lot more than that. But doing that standup every day ensures that there is at least a minimum of communication, every day.

Re: Scrum disempowers developers

#305

Post by nradov »

mlthoughts2018 wrote: post #215
nradov wrote: post #207

Earlier quoted context omitted.

There is no particular burden of proof. No one cares whether you approve of Scrum or not. But what are you comparing Scrum to? Define your specific objections and propose an alternative.

I'm comparing Scrum to customized, situation-specific workflow practices created and adopted by the team that will use them, based on what works for that team. What about Scrum uses evidence to convince a team to believe it should deviate from that? > "No one cares whether you approve of Scrum or not." If you don't want to participate in a discussion about it, why are you? Statements like this are useless. We're talk…

You're comparing Scrum to a phantom. State which specific practices work better than Scrum in specific situations. Otherwise it's just a complaint with no useful contribution.

Re: Scrum disempowers developers

#306

Post by s73v3r_ »

matthewmacleod wrote: post #21

I find this article lacking, because it makes all of the same mistakes typical of these bandwagon anti-Scrum articles. Despite working in a a Scrum team, I recognise literally nothing of the problems that are described. Our product owner works closely with both commercial and development groups to build the backlog. Pressure to build good technical solutions is reasonably balanced with commercial requirements. The de…

I think very, very few articles actually want to touch on the reason that Agile/Scrum goes bad: Lack of management/client buy in. If management or the client aren't going to work in an agile manner as well, then that just puts the devs at a disadvantage, and makes for a crappy work environment. Devs lose any agency they had in terms of what to work on, and as a result become disgruntled and stop caring about the work.

Re: Scrum disempowers developers

#307

Post by nradov »

s73v3r_ wrote: post #298
nradov wrote: post #268

Earlier quoted context omitted.

The business benefit of having a longer planning horizon is that it enables making some commitments outside the agile team. In the real world sometimes that's necessary. A sprint cadence also helps ensure that the team does real retrospectives rather than putting those off. But certainly Kanban can work as well or better in some environments. Pick what works for the circumstances.

I definitely feel that once something has gone into "maintenance mode", where most of the work of making the project exist is done, then Kanban can be much better for organizing work.

Sure maintenance engineering is usually a good fit for Kanban. If a high priority defect report comes in you don't want to have to wait two weeks to include it in the next sprint plan. Just move it to the top of the backlog and fix it tomorrow.

For larger products with multiple teams working on the same code base it can even work to have a mix. The feature development teams follow Scrum (or something similar) and the maintenance teams follow Kanban.

Re: Scrum disempowers developers

#308

Post by s73v3r_ »

alistairSH wrote: post #110
barrkel wrote: post #75

Earlier quoted context omitted.

I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.

IMO, this is where a good leader (SM, tech lead, whoever - I don't mean a literal manager) advocates for sanity on behalf of the rest of the team. Mostly, this just requires somebody to say "No." every so often in the face of ridiculous demands. As SM, it's my job to ensure that not only will the PO listen to concerns from the team, but the team feels empowered to provide that criticism. If neither of those happens,…

While that's great, the boss is still the boss. I don't feel that any kind of parity can really occur when one party has the ability to pull the, "Do it this way and in this time or I take away your ability to feed and house your family," card. And while the vast majority of managers will never come out and say this, or try to not imply it, the implicit threat is still there.

Re: Scrum disempowers developers

#309

Post by s73v3r_ »

stronglikedan wrote: post #264
barrkel wrote: post #75

Earlier quoted context omitted.

I recognize the disfunction. What happens is that the owner of the backlog becomes the controller of how much time gets spent on what. With feature pressure, it's all new features all the time, with no scope to address debt.

> the owner of the backlog becomes the controller of how much time gets spent on what. Then it's no longer Scrum, correct?

I mean, if you want to do the "No True Scotsman" thing, sure. But I think it's really counterproductive to handwave away a lot of the common problems that occur.

Re: Scrum disempowers developers

#310

Post by s73v3r_ »

tootie wrote: post #58

Our weekly "why scrum sucks" post that's really a "why my company does scrum wrong and I don't know how to fix it". Product owners push customer value. Of course. You should too. Code quality and refactors have business value. Reduced maintenance cost, fewer bugs, faster future dev. If you can't explain that to your product owner then maybe it's not worth doing. I think your big missing piece is the collective owners…

"why my company does scrum wrong and I don't know how to fix it"

Well, because more often than not, the answer is management, and there's really no way to fix bad management.

Post reply on HN