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

101–110 of 382 posts

Re: Scrum disempowers developers

#101

Post by specialist »

rch wrote: post #90
specialist wrote: post #78

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".

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.

Re: Scrum disempowers developers

#102

Post by nradov »

specialist wrote: post #77
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…

Scrum is antithetical to quality. We're 20 years into this experiment? I have yet to even hear someone tell a compelling narrative about doing QA/test in an "agile" context.

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.

Re: Scrum disempowers developers

#103

Post by christophilus »

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 without much need for fancy management practices.

If any dev managers are reading this, I can say, this approach works, and you should give it a try.

Re: Scrum disempowers developers

#104

Post by jrochkind1 »

> the product owner often works alone and the development team simply receives a stream of backlog items that need to somehow be brought into a cohesive whole

This is the root of the problem in my opinion.

I am not interested in defending "Scrum", I don't like what I know about it, in the few experiments I've been involved in with it (not by choice), I agree it was disempowering to developers, trying to treat developers like commodities.

However, I am a fan of trying to do things agilely (iteratively, figuring out what to do next in relatively short chunks without trying to plan out the next year+).

In the experiences I've had where this _worked_ the product owner was _intimately_ involved with the development team, with lots of communication in both directions, with the development team's info and feedback effecting how the product owner prioritized and determined (and changed, agilely) acceptance criteria.

The product owner had to embrace/accept that this would be a significant time and energy commitment to them, they could not be looking to minimize their time here, and had to accept that "with great power comes great responsibility" -- that they needed feedback from developers to make these decisions properly.

On the flip side, through these good experiences, I also learned that a good product owner is _so important_ -- as a technical decision-maker I don't _want_ to be responsible for determining product priorities or acceptance criteria. I want my feedback to be taken into account, but having someone else (who is good at it) be _responsible_ for it let's me focus on applying technical excellence to achieve the goals set by the PO, and takes _so_ much pressure and anxiety off of me. Especially when I can trust them to know what they are doing it and do it well (just like they can trust me to execute well).

I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".

Re: Scrum disempowers developers

#105

Post by tannhaeuser »

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…

No, it's the other way around: those arguing against SCRUM don't have to tell their reasons (bad experience suffices), but SCRUM proponents must come forward with logically sound and coherent arguments pro-SCRUM in the first place.

Re: Scrum disempowers developers

#106

Post by specialist »

regularfry wrote: post #89
specialist wrote: post #77

Earlier quoted context omitted.

Scrum is antithetical to quality. We're 20 years into this experiment? I have yet to even hear someone tell a compelling narrative about doing QA/test in an "agile" context.

https://continuousdelivery.com/implementing/patterns/ and https://continuousdelivery.com/foundations/test-automation/ would be your starting point there.

Yaya. Thanks for the links. Will review.

FWIW, I'm desperately trying to bring "TEST in PROD" style continuous delivery whozeewhatsit to my current team.

When in Rome, join the third millennium, old dog new tricks.

I still can't imagine I can get back to the 90s (quality wise). But if there's a way, I'm gonna find it.

Re: Scrum disempowers developers

#107

Post by walshemj »

gerbilly wrote: post #93

From what I could tell, most workplaces use scrums to enforce a minimum starting time for all their developers. They would typically schedule an early in person scrum meeting to defeat all the devs that like to work late or remotely.

From my experience though using DSDM end of day standups are better.

It also helps where team members have different commutes and stops wasting the time of early arrivers. I regularly used to be first in the office even though I had a 70 mile commute to London when compared to my co workers who lived in London.

Re: Scrum disempowers developers

#108

Post by specialist »

nradov wrote: post #102
specialist wrote: post #77

Earlier quoted context omitted.

Scrum is antithetical to quality. We're 20 years into this experiment? I have yet to even hear someone tell a compelling narrative about doing QA/test in an "agile" context.

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.

Agree about futility of testing towards quality.

Source: Former QA/Test manager.

Re: Scrum disempowers developers

#109

Post by nradov »

lmm wrote: post #69
mattbrewsbytes wrote: post #25

The teams I've been on that just 'jive' usually start with some process framework but then evolve to just work well together. There are strong philosophies in Scrum and Agile that should be kept as guidelines. The key is being agile (lower case 'a') so you can adapt to changing priorities. Continuous Integration/Continuous Delivery go a long way towards empowering developers. Two ways to tackle technical debt in proj…

> Two ways to tackle technical debt in projects: Disagree with tackling it as a separate activity at all - that's a way to get useless churn as you move towards an architecture you think is better rather than one that meets your actual needs. Do continuous improvement instead: improve the part of the codebase you're working on in a way that also contributes to your immediate, customer-facing task. "Make change easy,…

We have minor refactoring baked into our definition of done, so when agile team members run across existing code that doesn't meet current standards then they're supposed to just go ahead and refactor it on the fly. Since it's part of the definition of done, it's not "extra" work and is accounted for in the user story points estimate.

Larger refactorings that impact multiple modules have to be treated as separate user stories and prioritized based on business value just like everything else.

Re: Scrum disempowers developers

#110

Post by alistairSH »

barrkel wrote: post #75
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 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, I've failed.

A bad PO will RUIN a team. I've seen them do just what the blog entry claims. I've also worked with POs who don't do any of the bad things claimed.

Post reply on HN