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

231–240 of 382 posts

Re: Scrum disempowers developers

#231

Post by srtjstjsj »

knoq wrote: post #223
mwilliamson wrote: post #98

I think the value I get out of Scrum, or XP, or any other methodology, is two-fold. Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your t…

Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate why TDD is part of the "agile toolset"? I've seen this claim multiple times and it's never made sense to me. I do TDD on side projects where there's not even a hint of "agile."

Agile -> YAGNI -> TDD

Agile warns against building stuff you don't need. TDD means that test provide the justification for feature work. If your feature work isn't making a failing test past, you don't need that feature work. Obviously this assumes that your tests are justified (ideally there is a stack of tests leading all the way to the end user experiment), but that's much easier to get right than justifying untested feature work.

Re: Scrum disempowers developers

#232

Post by srtjstjsj »

tannhaeuser wrote: post #124
struppi wrote: post #45

If you do Scrum like that, you're doing it wrong (I know, no true Sctosman [1], and I know, there are actually dark patterns [2]). I wrote a whole book about "Agile Anti-Patterns" [3]. Most of the book's content is about things that many companies get wrong when they start with agile or lean software development. Because it is very easy to get those things wrong. Yes, those problems are extremely common. Not only wit…

That sounds ridiculously similar to people hanging on to communism/socialism: "the principles are sound, it just hasn't been implemented as intended". Except, just like communism, Scrum has never and will never be implemented "as intended" because that's contrary to our collective evolutionary gifts, and against a developer's desire to find satisfaction in good craftsmanship. A project management methodology building…

That also sounds ridiculously similar to people hanging on to capitalism: "The free market is the best way to run an economy, it's just that there has never been a free market in the real world."

Re: Scrum disempowers developers

#233

Post by lmm »

js8 wrote: post #220
lmm wrote: post #186

Earlier quoted context omitted.

> There might not be a clear consensus what a given person does but there are three types of tasks or concerns on the project, as I outlined them. Do you disagree with that? That's one way to break down the set of tasks/concerns you've identified, sure - but only one. I don't think that the industry as a whole accepts your categorisation into three, or even your paradigm for which tasks do and don't need addressing i…

No, you misunderstand. I don't care about the breakdown, but I do care about these tasks and concerns (and you seem to agree that they exist). How to deal with them needs to be explained in the context of the new methodology, and how it relates to the old ones. That's what I have not seen with Scrum, it pretty much ignores all the history of project management as a discipline. And actually, when I started programming…

> I do care about these tasks and concerns (and you seem to agree that they exist).

Not really, and I don't think the industry as a whole does either. Everyone has their own set of tasks and concerns; I don't think there's any consensus that says that all the important ones are on your list, or that everything on your list is important.

Re: Scrum disempowers developers

#234

Post by fwip »

wpietri wrote: post #125

This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all. The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing contr…

About a year ago, we went from no-process to "agile?? I guess?"

And let me tell you, a badly implemented process is a great way to turn self-driven developers into cogs that just do what's in Jira. Getting your tech decisions questioned by non-tech scrum masters during standup, requirements that don't arrive till midsprint, inability to deploy anything that hasn't been specifically inspected by the sole overworked product owner, etc.

It's not intellectual laziness, it's a defense mechanism. You can't be emotionally invested in your work if the process makes things worse for everyone, at least not without a good therapist.

Re: Scrum disempowers developers

#235

Post by srtjstjsj »

JepZ wrote: post #42

> Scrum has become the de facto definition of Agile That is a part of the problem. Scrum is very far from Agile. Scrum introduces processes and tools while the Agile Manifesto [1] clearly states: > Individuals and interactions over processes and tools That said, Scrum isn't entirely bad. Its just not what many people think it is. As a tool to change the culture of a company that has been shaped by classical project m…

The Scrum process is a set of tools to push individuals into interaction instead of hiding from each other.

Re: Scrum disempowers developers

#236

Post by mwilliamson »

knoq wrote: post #223
mwilliamson wrote: post #98

I think the value I get out of Scrum, or XP, or any other methodology, is two-fold. Firstly, it gives you a set of tools to use -- sprints, TDD, product owners, and so on -- that should work well together. To use them well, I think you both need an understanding of how each of those tools supports some idea or principle that the methodology promotes, and whether or not you think that principle is important for your t…

Not disagreeing (though not a fan of Scrum or Kanban), but can you elaborate why TDD is part of the "agile toolset"? I've seen this claim multiple times and it's never made sense to me. I do TDD on side projects where there's not even a hint of "agile."

Rapid feedback and short iteration cycles are often considered to be an important part of agile development. TDD suggests that you write a test first, and try to make that test the smallest increment that moves you forward. It feels to me that TDD is an application of the principles of rapid feedback and short iteration cycles on the level of code.

If you think using TDD improves the quality of your code, then it's also important for maintaining high code quality, since that enables some of the other agile practices, such as frequent releases.

I don't worry too much about whether a particular practice is agile or not. If you find TDD useful, then great! It's often included in conversations about agile development, but that doesn't mean you have to be doing agile development in order to use it.

Re: Scrum disempowers developers

#237

Post by srtjstjsj »

Robin_Message wrote: post #191
bartmcpherson wrote: post #30

Why would you let yourself get so stuck in the minutia of SCRUM? Use the parts you need and not the parts that work against you. The value usually listed first in the agile manifesto is "Individuals and interactions over processes and tools".

To quote one last bit of minutiae: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." I agree with what you're saying, but Scrum says not to modify it. That's one of my problems with it.

> implementing only parts of Scrum is possible

Re: Scrum disempowers developers

#238

Post by srtjstjsj »

fwip wrote: post #234
wpietri wrote: post #125

This is a good article, but I disagree that Scrum's major flaw is a lack of hierarchy on the development teams. I've worked on some great self-organizing teams, and they're more than equal to the product manager. They outnumber the PM, after all. The problem only comes in an organizational culture of "whatever the boss says". In that context, teams rarely learn to self-organize. Instead, the previously existing contr…

About a year ago, we went from no-process to "agile?? I guess?" And let me tell you, a badly implemented process is a great way to turn self-driven developers into cogs that just do what's in Jira. Getting your tech decisions questioned by non-tech scrum masters during standup, requirements that don't arrive till midsprint, inability to deploy anything that hasn't been specifically inspected by the sole overworked pr…

> questioned by non-tech scrum masters during standup,

Standup is for raising issues, not answering questions. Standup rules says to defer discussions to a separate meeting.

> requirements that don't arrive till midsprint,

Not scrum-specific, and scrum requires either (a) not doing that, or (b) negotiating a trade to remove another requirement.

> inability to deploy anything that hasn't been specifically inspected by the sole overworked product owner

Not scrum at all. Scrum deploys every month, as clockwork, with whatever is built so far.

Re: Scrum disempowers developers

#239

Post by ownagefool »

nickelcitymario wrote: post #36

Like any and every business theory, Scrum has one or two core ideas that are awesome, but could be explained adequately in a paragraph or two. This does not sell books and consulting, so it evolved into a field of its own. The fact that there is so much B.S. in Scrum doesn't mean that it has nothing of value to offer, though. Here's what I get out of it: 1. Sprints are a better way to organize than Waterfalls. I've e…

I can probably agree that sprints are usually more realistic than old school waterfall (arguably it depends, like all things) but why do we feel the need to perpetually sprint?

A simple kanban board seems to give all the same benefits without the constant pressure and weekly death march to meet the end of sprint commitments.

Re: Scrum disempowers developers

#240

Post by simonswords82 »

rwmj wrote: post #208
mmusson wrote: post #74

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. I think the focus on methodologies is to get a good result from an uneven team. Companies desperately want to treat programmers like standardized workers that can be mixed and matched as needed. The siren song of the methodology is that maybe it can achieve that goal. I have never seen this work in practice. There are no quick fixes. People can im…

My experience is that a good team does a good job. A bad team doesn’t. My experience is that sprints interrupt my workflow to such an extent that I can no longer get anything done. In other words, they make a good team bad.

How so? I'd be keen to hear just in case I'm unwittingly inflicting similar pain on my developers.
Post reply on HN