Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#211

Post by srtjstjsj » Wed, May 30, 2018, 3:44 PM UTC

kevstev wrote: post #148

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 quip on scrum/agile is that it "ensures mediocre results from mediocre teams." Its just a methodology in the end. It can help keep those that tend to have wandering minds focused, but for high performing teams the overhead slows them down. The assumption of a standard programmer is just never a reality as well. I actually saw a startup try to go full religious agile and only hire "full stack" developers to try to…

"Agile" is completely independent concept from "full stack" or "homogenized" development.

Re: Scrum disempowers developers

#212

Post by srtjstjsj » Wed, May 30, 2018, 3:46 PM UTC

some_account wrote: post #112

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…

I really dislike agile. A product owner asked me once if I get some benefit from them...and no, I don't. Thry get a lot of benefit from me sharing what I'm doing because they can then keep track of it and communicate it to other people, but I don't get any benefit personally. I want to be the guy who talks to the rest of the employees, implements things and get direct feedback from them. I dont want anyone in the mid…

Why haven't you told your manager that you are willing to do your job plus the product owner's job for only your pay plus half the product owner's pay?

Re: Scrum disempowers developers

#213

Post by knoq » Wed, May 30, 2018, 3:46 PM UTC

christophilus wrote: post #103

jillesvangurp wrote: post #92

Pretending to do agile seems to be widespread thing in our industry. There are literally no companies out there not claiming to be agile. So, the word has become meaningless. Scrum is the lowest common denominator in our industry when it comes to that. Agile implies getting things done and getting things to market. If scrum helps you do that great. If not, ditch it. In my experience, Kanban is a step up on the evolut…

My company doesn't claim to be agile, I don't think. We just allow devs to work on whatever they find interesting. If something really urgent comes up, its urgency is made known to the dev team at large, and someone always steps up to the plate. Works fine for us! Also, we don't have deadlines. Things ship when they are "good enough". Granted, we're very selective in our hiring process, but it means things just work…

A previous company I was at worked this way and it was a dream. That said, it does require very selective screening processes and maturity from those you do hire.

However, it was the most happy / least stressed I've ever been in my life. I still get beers almost weekly with over half that team. This "strategy" really built comradery because we were always talking and discussing rather than leaving comments on some Jira ticket (which we did for async or when necessary).

Seriously.... give it a shot if you can

Re: Scrum disempowers developers

#214

Post by srtjstjsj » Wed, May 30, 2018, 3:47 PM UTC

specialist wrote: post #195

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…

"...there is no well defined goal nor can one exist." Consulting is the pejorative we gray beards used for that activity. You reminded me of another pithy throwaway line: Agile didn't improve outcomes, it just reduced the cost of failure, allowing teams to fail many more times with the same budget.

So, agile improved outcomes? I'd love to have 1 big win a year and 11 cheap losses, than 5 expensive losses and then bankrupt before a big win.

Re: Scrum disempowers developers

#215

Post by mlthoughts2018 » Wed, May 30, 2018, 3:47 PM UTC

nradov wrote: post #207

mlthoughts2018 wrote: post #192

Earlier quoted context omitted.

I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it . My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained withou…

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 talking about high-level evaluation of Scrum.

It's like you would read the original post in the OP, which is a qualitative discussion. And instead of formulating reasonable discussion points, you'd just leave a comment saying, "No one cares what you think."

At that point, I mean, your opinion's decided. Why are you even here? What is the goal? To shoot down anyone who tries to analyze Scrum in a bigger picture sense and just give them a raspberry?

Re: Scrum disempowers developers

#216

Post by srtjstjsj » Wed, May 30, 2018, 3:48 PM UTC

specialist wrote: post #101

rch wrote: post #90

Earlier quoted context omitted.

But you have to include 'estimates', which ruins everything (in non-trivial cases, yadda, yadda).

Estimating is my Achilles heel. Always has been. I'm way too optimistic. My workaround was to do jelly bean estimating. Get guesses from everyone, then use the average. Worked surprisingly well. We did other things to meet that target date, honor that estimate, of course. But that's a longer story.

Nothing protects against toxic management.

"Evidence Based Scheduling"

https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...

Re: Scrum disempowers developers

#217

Post by [deleted] » Wed, May 30, 2018, 3:51 PM UTC

[deleted]

Re: Scrum disempowers developers

#218

Post by lmm » Wed, May 30, 2018, 3:52 PM UTC

PeterisP wrote: post #158

vannevar wrote: post #140

Earlier quoted context omitted.

My experience is that a good team does a good job. A bad team doesn’t. Of course that's your experience. If you judge teams based on outcomes, then you're going to conclude that teams that succeed are good, and teams that don't must be bad. Unfortunately that offers no guidance in how to become a good team. The goal of software management as a practice is to find patterns of positive behavior that make good teams. Ag…

The observation is more about people. You take random people from good teams, mix em up and put them in a very different environment, they're still going to do a good job. What if there is no reasonable and reliable way to become a good team, and the only way to go from a bad team to a good team is to replace most of the team?

Then it would be good to figure that out, measure that, and then at least we can put the best people on the most important projects. It's perfectly possible to imagine a world where e.g. developer IQ was the only thing that mattered and the quality of software that got produced was simply proportional to the average IQ of the developers who worked on it, sure.

I don't think that's the world we live in though. I've seen smart, sociable, effective developers fail in misorganised teams, and I've seen teams of ordinary people produce very good software by getting their processes right.

Re: Scrum disempowers developers

#219

Post by srtjstjsj » Wed, May 30, 2018, 3:52 PM UTC

dgreensp wrote: post #167

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…

Having worked at primarily at “informally agile” software companies in Silicon Valley (and I count Google as one), I see an important bit of truth in the article that Scrum ideas have become the embodiment of agile, and ideas from Scrum that may not make sense in isolation have become standard practice in software development and are somehow seen as the alternative to “waterfall” development, even if they have nothin…

Where has management forced Scrum onto a team that was already successful?

Re: Scrum disempowers developers

#220

Post by js8 » Wed, May 30, 2018, 3:52 PM UTC

lmm wrote: post #186

js8 wrote: post #155

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? So if Scrum (or any other methodology, for that matter) wants to define a new role (to what end?), they should explain, how they are related to these concerns? What tasks that were traditionally done by the triad are supposed to be done by the new…

> 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 professionally, I didn't think that management was necessary, and that we could self-organize and all that. But as I changed projects and bosses, it turned out, I just had a good manager (and it was a waterfall-like method, by the way).

So I think the idea of self-organization is intuitively appealing to many people (especially young without any experience), and if you have a person in the team who can naturally take each of these roles, then I think it can work (that is - sometimes). But today, I don't think it will work in general, and for that reason.

Now I recognize that, for instance, you need somebody well-organized on the team who can make sure things do not fall under the table. Or you need somebody who is process-oriented, interested in improving process. Then self-organization can work.

If you don't have people with specific traits like that, or they don't emerge as natural leaders (gain respect) in their specific areas of interest, then you need to appoint somebody to have that role. Then it makes sense to have explicit project manager, or product manager, or architect, who focus on certain tasks and concerns.

I suspect the fact that sometimes you can do without having these people designated as such can account for some anecdotal success of Scrum (or any other method - I personally had the best experience with waterfall-like approach).