Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#271

Post by ggregoire » Wed, May 30, 2018, 5:04 PM UTC

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 completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company.

I've a SCRUM master certification and still, I follow only what's good for us.

It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in the backlog.

It's also totally fine to allow the technical lead to add his own tasks to the sprint. You can do 80/20 for instance (business/technical values). It's not going to kill your business and will make your developers happy (SCRUM is about people, not process, right?).

Re: Scrum disempowers developers

#272

Post by conatus » Wed, May 30, 2018, 5:05 PM UTC

mlthoughts2018 wrote: post #256

conatus wrote: post #251

Earlier quoted context omitted.

Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhe…

I wish more Scrum-advocates shared your opinion. Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum. The reason I feel the need to deeply question it though, is that most managers…

Doubtless scrum can be imposed from above as a management tactic. This would open to more wider discussions about how power operates in workplaces.

I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit more before answering.

But in a couple of cases I've seen it was sought by the team "from below" to protect the quality of their work, make work more enjoyable and self-organised and basically work to more reasonable timescales. There is something to scrum being a toolbox you can use and having a brand. It means you can ask for a process and people know what you mean. Rather than say "I wish work was better".

Re: Scrum disempowers developers

#273

Post by alistairSH » Wed, May 30, 2018, 5:12 PM UTC

yebyen wrote: post #149

alistairSH wrote: post #120

Earlier quoted context omitted.

With turn-over like that, nobody is going to be successful. What is driving the turn-over? Are team-members being moved elsewhere, or are the quitting out of frustration? As for training for the SM (or PO, or anybody else), it's a continuous process. The CSM is a starting point, a basic level of understanding. At my office, many of us have gone on to take the Advanced CSM course. Most of us attend meet-ups, conferenc…

> What is driving the turn-over? Are team-members being moved elsewhere "72%" is really misleading... from the original team of 2 developers and one PM/Scrum-Master, the Scrum-Master was promoted to a newly formed team, and the other developer is still with us, but in a mostly consulting-only capacity, as she is focused on other projects in our team. Nobody is quitting out of frustration. (Not yet anyway!) We've sinc…

overridden by the PM's boss

Yeah, lack of buy-in from senior management is probably the biggest single problem with scrum, any other agile framework, and probably even non-agile frameworks.

Interesting that you're in higher ed. I am as well, thought it sounds like you're at a college/university and I'm at a software company selling into that market.

Re: Scrum disempowers developers

#274

Post by alistairSH » Wed, May 30, 2018, 5:19 PM UTC

dgreensp wrote: post #187

Cthulhu_ wrote: post #159

Earlier quoted context omitted.

This is correct. The article (and grandparent) seems to quickly jump to the assumption that the members of a scrum team are mindless drones - and don't get me wrong, some scrum teams are - but they are empowered by scrum itself to have a say or two itself in what to deliver when. The PO only decides priorities, and is not (officially) allowed to pressure for time and deadlines. In return, the scrum team gives feedbac…

Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them. For example, Scrum says responsibility for op…

not having officially recognized responsibilities

I feel like that's a bit of an overstatement. While scrum advocates for shared responsibility, it doesn't demand no-titles, no-roles, or no-passions.

It's all about ensuring the entire team possesses 'T' shaped skills. Depth and expertise in some areas, but still generally knowledgable across all areas. My test engineer doesn't write much code, but in a pinch, she can. My PO is fully capable of "running" the team in my absence, as is the test engineer. All my developers know the full DevOps pipeline and can contribute to it, though none of them are DevOps engineers by title or primary responsibility. And I'm an ex-developer-now-manager who can do a bit of everything, though these days I'd rather go to meetings and play office politics so my developers can do their thing.

Re: Scrum disempowers developers

#275

Post by nradov » Wed, May 30, 2018, 5:19 PM UTC

Clubber wrote: post #262

nradov wrote: post #102

Earlier quoted context omitted.

I'm not sure where you got that mistaken idea. The Scrum values explicitly call for "shippable quality" by the end of every sprint. Other than that, Scrum doesn't explicitly define testing practices so do it however you like. But I would note that you can't test quality into a product.

Shippable quality to me is a full regression test. That's awful hard to do in the few days a 2 week sprint allows.

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, integration, system, performance, etc) are working.

Re: Scrum disempowers developers

#276

Post by 0xfeba » Wed, May 30, 2018, 5:25 PM UTC

captainbland wrote: post #116

I agree with the criticisms of Scrum on the whole. However I find it bizarre that this article and the other one it links to (which quotes Milton Friedman, which ought to be enough to raise eyebrows by itself) crticises organisations which market themselves as non-hierarchical (or in the marketing lingo 'holacracies') when they clearly adhere to hierarchy if you think about it in any depth, just a badly organised one…

Yes I thought the jab at Valve was a cheap shot; very poorly supported.

Re: Scrum disempowers developers

#277

Post by geezerjay » Wed, May 30, 2018, 5:25 PM UTC

Clubber wrote: post #252

geezerjay wrote: post #246

Earlier quoted context omitted.

> Consulting is the pejorative we gray beards used for that activity. Those hypothetical gray beards may come up with all the pejorative terms they need, but that only hides the fact that they are entirely oblivious to the reality of running a successful software project, one which actually meets the client's requirements and delivers working products. Therefore, they spend their time coming up with pejorative terms…

>but that only hides the fact that they are entirely oblivious to the reality of running a successful software project Wow, amazing that the shoulders of the giants you stand on was never a successful software project. >In the old timey's waterfall world, a waterfall project that's executed flawlessly is a project that ends up delivering the wrong product that fails to meet the client's basic needs, thus leading to a…

> Wow, amazing that the shoulders of the giants you stand on was never a successful software project.

Those giants you're referring to made a lot of mistakes along the way.

One of those mistakes was blindly trying to force project management practices that were driven by the need to allocate material resources into projects where the only resource that's allocatable is man-hours. In projects whose success is determined by how well are material resources spent, redesigning something midway is something that's entirely unthinkable and can even dictate the project's death. That's not the case in software development projects, where the only resource is the fixed amount of man-hours that's at the project manager's disposal. With the development and adoption of a couple of software engineering practices aimed at preserving the project in a deliverable state, redesigning entire modules is essentially free. Therefore we end up with project management challenges that superficiality may appear to be the same but are actually fundamentally different.

Therefore, different types of constraints result in different optimization problems that lead to different solutions and require different approaches.

> Waterfall was iterative as well, when the needs changed, so did the project plan.

The keyword you've used is "needs". You're assuming that changes are exceptional. They are not. In software projects, requirement changes are the norm, not the exception. Changes aren't needed, they are constant. If your goal is to meet the client's needs then you need to meet the client's needs, and not some line in the sand that has no bearing with the paying customer's goals.

> Based on your comment, I suspect you've never done anything outside of scrum / agile, so you are comparing it to some mythical way of doing things you heard about (undoubtably from scrum consultants.)

You suspected wrong. In fact, I have far more years of experience in waterfall projects in real world engineering projects than in scrum/agile. Waterfall projects make sense when the requirements make sense. Software development projects based on basic software engineering practices don't incorporate some fundamental requirements found in engineering projects, thus their efficiency can and does improve by following adequate practices.

Re: Scrum disempowers developers

#278

Post by mlthoughts2018 » Wed, May 30, 2018, 5:26 PM UTC

conatus wrote: post #272

mlthoughts2018 wrote: post #256

Earlier quoted context omitted.

I wish more Scrum-advocates shared your opinion. Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum. The reason I feel the need to deeply question it though, is that most managers…

Doubtless scrum can be imposed from above as a management tactic. This would open to more wider discussions about how power operates in workplaces. I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit m…

When it is sought by the team, consensus-wise, "from below" -- I would absolutely support it. That is the team telling you what works for them, not the management telling the team how it must work.

Re: Scrum disempowers developers

#279

Post by s73v3r_ » Wed, May 30, 2018, 5:29 PM UTC

ggregoire wrote: post #271

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 completely agree. I don't get why people try to strictly follow the methodology (and then complain about it) instead of just taking the core of it and apply what work for them and their company. I've a SCRUM master certification and still, I follow only what's good for us. It's totally fine for me to add a task in a current sprint. If you care about finishing the sprint, you just move a task of same points back in…

Problem is, that's a recipe for management ignoring all the stuff that gives developers power and agency, and taking all the micromanaging things.

Re: Scrum disempowers developers

#280

Post by nradov » Wed, May 30, 2018, 5:30 PM UTC

vinceguidry wrote: post #122

mikekchar wrote: post #55

Earlier quoted context omitted.

> If I had to pick the most destructive part of Scrum, it's the sprint commitment. I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following: - Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agr…

How do you organize acceptance criteria? Is it language that has to be added to every story?

Every user story should have acceptance criteria (confirmation). Otherwise how will you know when you're done? One common technique for organizing acceptance criteria is to write them in user voice form: "As a , I want to , so that ."

https://www.scaledagileframework.com/story/