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

331–340 of 382 posts

Re: Scrum disempowers developers

#331

Post by jrochkind1 »

dnomad wrote: post #185
jrochkind1 wrote: post #104

> 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 develop…

A "one way" product owner is useless. Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it might be the most important thing. If developers and all the owners are not continually reviewing the items in the backlog together, clarifying them and making sure everybody understands what is being asked for and what the priorities are, breaking down stories that are too big, making sure that, yes, some…

I'm not sure if you are arguing against what you quoted from me (that I think a technical lead is neccesary, cause it is a "who"), but the reason I come to this conclusion from my experience is because technical decisions on the macro or medium level need to be decided on a fairly regular basis, and I do _not_ want continual endless consensus committee meetings hashing them over. Or a free-for-all with no coordination.

It is not only more efficient, but better for morale to have an agreed upon person upon whom the buck will stop. Sometimes when things are "everyones" responsibility they end up actually having nobody take responsibility for them. Such a person with ultimate responsibility and authority for technical decisions should be both competent and not an asshole, they should be in constant dialog and taking feedback from everyone else, and paying real attention to their concerns about technical matters.

But for the same reason you need a Product Owner (instead of just the amorphous group of all stakeholders) to ultimately take responsibility for decisions about priorities and acceptance criteria, you need a technical lead to ultimately take responsibility for technical decisions.

I think that "Scrum" doesn't have this is just part of it's attempt to commoditize developers (something I think is characteristic of "scrum" but not part "agile" generally or at it's best). "Scrum" sometimes seems as if it's designers thought there _are_ no technical decisions to be made, just a bunch of widget-ized, swappable developers churning out code to meet the requirements set by the PO. But, in fact, there are technical decisions to be made, that will effect other people's work and the product as a whole, in the short- and long-terms. Regularly.

Re: Scrum disempowers developers

#332

Post by tonyarkles »

jrs95 wrote: post #65
watwut wrote: post #28

Earlier quoted context omitted.

Awesome software development process that is not about communication: testing by testers. Also code and documentation review. Also, keeping tasks in tracker and having version controll. Etc.

Code review definitely is about communication. That’s arguably it’s biggest benefit. The author could test something himself, but code review facilitates a conversation and keeps people on the same page.

My experience is that people often can't test what they've been doing by themselves. They've got blind spots and assumptions that they can't see. They have a mental model for how a feature is supposed to work, and they test that mental model, but they don't test outside of that model.

Re: Scrum disempowers developers

#333

Post by wolfi1 »

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…

>1. Sprints are a better way to organize than Waterfalls. I've experienced this over and over again personally, so I'm sold on this.

There are so many people who say, Agile or Scrum, respectively, do not need specs, the specs are just incremented with every sprint as the product itself, leading to software projects with undefined goals and overlong project time

Re: Scrum disempowers developers

#334

Post by tootie »

nradov wrote: post #275
Clubber wrote: post #262

Earlier quoted context omitted.

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…

Scrum does not require automation at all. Generally speaking, it should, but full automation is folly and dependence on automation is an anti-pattern. You simply can't test everything without eyes. Usually when you automate as soon as something is built, you tend to automate what it does instead of what it's supposed to do. You're also trying to hit a moving target and will end up spending a lot of time maintaining your tests instead of actually testing. There needs to be a balance of automation and manual testing.

Re: Scrum disempowers developers

#335

Post by FrankyHollywood »

Dave has an interesting talk about it.

https://m.youtube.com/watch?v=a-BOSpxYJ9M

My personal experience is any project where scrum actually works is a boring project, no interesting problem is predictable.

Fortunately I see mostly frustrated scrum masters, not understanding why planning fails :)

Re: Scrum disempowers developers

#336

Post by wpietri »

cabalspecter wrote: post #126
wpietri wrote: post #91

Earlier quoted context omitted.

UML comes out of a different culture of development, that of the Rational software crew. They had their own much more heavyweight process than the Agile folks: RUP, or the Rational Unified Process: https://en.wikipedia.org/wiki/Rational_Software#UML_and_RUP There was a little overlap; in particular, Martin Fowler wrote an intentionally thin book called "UML Distilled". But the UML world was generally heavy on both up…

Too bad people didn't bother reading the Unified Process book, which clearly specifies the use of iterative and incremental development and the creation of just enough UML diagrams to communicate and document a system design. It even argues that working software should be used to describe an architecture in the Elaboration phase rather than a 10000 words document. It can actually be considered as one of the first agi…

I totally agree that it was taken over by zombies, and also agree it had some good ideas.

But I don't think it was quite as incremental and iterative as all that. One, it was more a "process framework" than an actual process, so iteration length could be whatever the grand poobahs wanted. They were entirely fine with multi-month iterations. Two, as the "RUP hump" chart shows, it was always pretty waterfall-ish. And three, whatever the words in the book, the RUP adopters were generally large-company shops, and he who pays the piper calls the tune.

I definitely remember the RUP people coming to the early Agile conferences and being very suspicious of our wild ways. So I'm not sure even its originators would have called it an Agile process.

Re: Scrum disempowers developers

#337

Post by jrochkind1 »

majormajor wrote: post #290
mlthoughts2018 wrote: post #243

Earlier quoted context omitted.

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission acc…

I often wonder if it would be easier to start from the top instead of trying to build those barriers from below. If your business leaders are prone to changing their minds at the drop of a hat, you probably aren't going to actually change that. Putting process in place to make it painful to do that is just going to cause pain for the people who have the decision imposed upon them - the CEO's just going to tell other…

Hypothetically, "agile" is about _allowing_ decisions to be changed at the drop of a hat, without causing pain for implementers. The whole point is accomodating that, that's what "agile" _means_, right? (One can argue this whole goal is impossible, but I don't think it is. If it is, it's a problem for any agile process, not just "low-end scrum." But I think there are _way bigger_ problems with thinking you can plan out all work and schedules a year in advance and stick to it and wind up with anything succesful).

Now, every decision (new or changed) has a cost to be implemented. Some more than others. If you have decision-makers who refuse to recognize that, and think the amount of work they can ask a given staff with a given level of skill to accomplish in a set time period is unbounded -- no process is gonna save you from misery.

Re: Scrum disempowers developers

#338

Post by tootie »

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.

It's really not possible to take stories from dev to QA, to remediation to release within a sprint without having idle cycles of either developers or testers. It's what make Kanban more appealing. The sprint boundaries can be useful guidelines, but I'd never hold anyone's feet to the fire over sprint commitments. I don't care about carryover so long as we have good rolling velocity.

Re: Scrum disempowers developers

#339

Post by wpietri »

majormajor wrote: post #290
mlthoughts2018 wrote: post #243

Earlier quoted context omitted.

> "If you go by actual behavior, it turns out the highest priority at most companies is not actually to improve, to get better at making things for users. It's instead to make managers and executives feel like something is being done without disturbing the power hierarchy. Low-end Scrum fills that need adequately, letting you move marginally in the direction of agility, apply some new labels, and declare "mission acc…

I often wonder if it would be easier to start from the top instead of trying to build those barriers from below. If your business leaders are prone to changing their minds at the drop of a hat, you probably aren't going to actually change that. Putting process in place to make it painful to do that is just going to cause pain for the people who have the decision imposed upon them - the CEO's just going to tell other…

Definitely. I think you're well on your way to reinventing what the originators meant by "Agile". The subtitle of the first Extreme Programming book, for example, is "embrace change".

I spend a couple of years at a startup I co-founded; requirements volatility was legitimately very high. We were very experimental, which meant we learned a lot, which meant frequent wild changes. We had a long-term vision, and plenty of theories about the future, but rarely planned more than a couple of weeks out.

This was honestly fine. The product manager (my cofounder) was really good at including us on the necessity of the changes, so it never felt irrational or out of control. Our process was highly tuned for minimum waste. And we were militant about a lot of quality-oriented practices, including unit and acceptance tests, pair programming, paying down technical debt, continuous deployment, frequent releases, and close collaboration with the product manager. That meant that however things changed, we were prepared.

I think if you can do it at a start-up that's shipping every few hours, it definitely works at much lower levels of requirements volatility. To me the real issue at scale is that if agency moves away from the team level and gets concentrated at the executive level, then decisions at least appear irrational, and often are because real-world information becomes ever more removed from the decision makers.

Re: Scrum disempowers developers

#340

Post by knoq »

mwilliamson wrote: post #236
knoq wrote: post #223

Earlier quoted context omitted.

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 a…

Makes sense. I just see them grouped a lot as if they are a "required dependency" for lack of a better phrase. Thanks
Post reply on HN