Scrum disempowers developers • Hacker News Board

Re: Scrum disempowers developers

#311

Post by magduf » Wed, May 30, 2018, 6:27 PM UTC

nickelcitymario wrote: post #154

walshemj wrote: post #83

Earlier quoted context omitted.

Oh bum I meant ISO9000 BS5750 is the Uk equivalent (and I worked at my first job on a joint project with the BSI on BS5750) But and its a big but some times you need the rigor a properly done waterfall process provides Air traffic control for example. You seriously don't understand the trade offs you make with "agile" vs waterfall? I have done both very successfully.

Nope, don't understand the trade offs if you're suggesting scrum is slower than waterfall. That just doesn't line up with my experience. "Results may vary," though. The issue I've had with every other project management approach is the illusion of structure. I'm not an expert on all or any approach. But my experience is that everyone wants me to be able to project, since absolute certainty, what my team can get done…

I don't think he was saying that waterfall is faster; I've never heard anyone say that. But WF is more rigorous and probably better suited for safety-critical software like avionics; the trade-off is that it lacks speed and flexibility.

Re: Scrum disempowers developers

#312

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

geezerjay wrote: post #301

s73v3r_ wrote: post #292

Earlier quoted context omitted.

"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 projects move on." I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are.

> I don't feel this is true at all. The issue is that most clients aren't willing to put in the time or effort to actually see what their needs are. You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements, that these requirements will and cannot change, and that software architects have perfect information and are able to make flawless choices r…

"You're assuming that it's realistic to expect that a requirements gathering process is able to precisely define all requirements"

No, I'm not. I am assuming it's realistic to expect that a company actually put some effort into finding out what they need, and getting us that information so that we can actually plan out a project.

"None of these assumptions hold even in conventional engineering projects."

Part of the reason for that is that companies don't do any of that research. They don't look at what they need; they think about what they want.

One of the biggest reasons people here dislike "Agile" is because management uses it as an excuse not to plan anything, and fly by the seat of their pants every two weeks.

Re: Scrum disempowers developers

#313

Post by TooBrokeToBeg » Wed, May 30, 2018, 6:30 PM UTC

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…

My initial thoughts...of course Scrum disempowers developers but that's not what the article is about. I see a hyperbolic title and a bunch of complaints about how "in the real world" things work differently (entrenched opposition will always sabotage progress).

What is a manager but someone who has control over the controlled? I'm surprised with so many ppl nodding their head at this list of complaints about bad software processes at bad companies, masquerading as analysis. If you think it takes more than 2 days to learn _how_ to be a Scrum master, you don't understand the role. It's not complicated, difficult, and time-consuming enough to require a singular employee...unless your process is already screwed up. Good luck finding whatever magic bullet you think will save you that isn't Scrum-based teams.

Re: Scrum disempowers developers

#314

Post by majormajor » Wed, May 30, 2018, 6:31 PM UTC

betenoire wrote: post #182

vannevar wrote: post #168

Earlier quoted context omitted.

A well-groomed backlog is not working code. So I don't get how that somehow means there's nothing to talk about. If there's an agile MVP, it's "write some working code, get feedback on it, then repeat until everyone's happy within some tolerance." Scrum is designed to increase feedback, but it's a floor, not a ceiling.

Sure, but the PM is there for a reason and the PM has roles. There is overlap with what developers can be doing, but we are trained/encouraged to punt to the PM for such decisions, questions, and suggestions. I get it, but it's now how I do my best work, proxying questions and discussions through a gatekeeper.

IME the PM works best when acting as a shield from random questions or future things or other not-important-this-instant distractions, but shouldn't block direct clarifying questions or feedback from you to a stakeholder. I'd keep them in the loop, but the ones I've worked with haven't wanted to just be a glorified "I deal with the goddamn customers so the engineers don't have to!" middleman for basic things like that.

Re: Scrum disempowers developers

#315

Post by pigleg » Wed, May 30, 2018, 6:48 PM UTC

Robin_Message wrote: post #197

pigleg wrote: post #172

I wouldn't fault it for lack of technical craft, that's not a specific statement in the original manifesto, except loosely maybe "working software". Largely forgotten now since more than a decade has passed, but even the poor implementation of Scrum has helped shut down the RUP hyper-documentation madness, massive unshippable releases with hundreds of bugs, etc. When trying to explain "Why agile?" to new devs out of…

In part one of this series ( https://www.lambdacambridge.com/blog/2018-05-how-scrum-destr... ) I explain how technical craft was key in all the agile methodologies, except Scrum. So I think that was part of the thinking in the original manifesto, but not expressed at the time (fish don't perceive water?) I suppose you're right that Scrum is better than waterfall deathmarches, but I hope we can do even better.

You assert that technical craft was key I think by inferring the bent of the associated methodology of each the people involved?

I don't agree, I think the main aim of agile was to solve the extreme dysfunction with the business-side and non-technical people, and there it has succeeded. (This is perhaps also reflected in your observation that XP interest has ebbed while scrum continues to climb in popularity.)

Have you had a look at the context inthe history statement in the manifesto: http://agilemanifesto.org/history.html

Quotes from that: "At the core, I believe Agile Methodologists are really about "mushy" stuff—about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in—and sometimes tremendous criticism of—Agile Methodologies is about the mushy stuff of values and culture."

"For example, I think that ultimately, Extreme Programming has mushroomed in use and interest, not because of pair-programming or refactoring, but because, taken as a whole, the practices define a developer community freed from the baggage of Dilbertesque corporations."

Re: Scrum disempowers developers

#316

Post by nlawalker » Wed, May 30, 2018, 6:50 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 feel like the books and consulting came from the fact that Scrum, while it can be explained in a paragraph or two, is very hard to reconcile with the idea that what the business wants is for you to be able to guarantee that you'll be "done" (and define exactly what that means) by a particular date in the future.

Re: Scrum disempowers developers

#317

Post by mlthoughts2018 » Wed, May 30, 2018, 6:51 PM UTC

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…

Generally the problem is that management wants this idea you call "just in time planning" to happen all the time, and even believes it to be synonymous to Agile. Meanwhile the software team is saying, that's fundamentally at odds with the entire premise of how to write software. Saying you want to produce software that was always planned at the drop of a hat (which is what management wants) is like saying you want to chisel Mount Rushmore but you won't tell whose faces should be on it until right at the end. It's just not a coherent goal. My hope with the barriers to anti-quality thing is that we would take things like this, where regardless of what management feels entitled to, and make it sacred and inviolable that the obviously stupid and incoherent things can be vetoed by the feet-on-the-ground people doing the actual work.

Re: Scrum disempowers developers

#318

Post by stronglikedan » Wed, May 30, 2018, 6:52 PM UTC

s73v3r_ wrote: post #309

stronglikedan wrote: post #264

Earlier quoted context omitted.

> the owner of the backlog becomes the controller of how much time gets spent on what. Then it's no longer Scrum, correct?

I mean, if you want to do the "No True Scotsman" thing, sure. But I think it's really counterproductive to handwave away a lot of the common problems that occur.

While it was a genuine question, I don't think the "No True Scotsman" fallacy applies at all, since that refers to subjective interpretation. IIRC, one of the objective rules of Scrum is that estimation of tasks is done by those who are to do them. If that is the case, and the owner of the backlog is estimating tasks, then it would appear that Scrum is not being practiced (or only partially being practiced, which may as well be not at all). I'm not sure how you interpreted any handwaving from a legitimate question, but I do agree with the point in general.

Re: Scrum disempowers developers

#319

Post by mlthoughts2018 » Wed, May 30, 2018, 6:54 PM UTC

s73v3r_ wrote: post #286

mlthoughts2018 wrote: post #265

Earlier quoted context omitted.

One example which I actually used to great effect in a previous team was that the team decides the relative allocation of backlog items between new features, fundamental research, maintenance, and refactoring / architectural design. The product owner, no matter how upper management is breathing down their neck, is not allowed to supersede that allocation. Once we got approval for this, it meant that product owner had…

So like everything in life, it all comes down to management. If management doesn't buy in, it doesn't matter how many processes you put in place, they're the ones that either hold the keys to success or failure.

Except that Scrum added time-wasting extra stuff on top of the situation.

If management doesn't buy in and I can operate my own low-overhead, low-formalism workflow, then so be it. I suffer the badness of management, but I don't also pay time waster costs for a formalized process whose sole purpose of better facilitating productivity is categorically disallowed in the first place.

I personally, as a matter of experience and opinion, would take it further to say that certain properties of Agile / Scrum actually add fuel to the fire and allow management's already bad behavior to manifest in even worse ways. But even if someone doesn't agree with that, I think the point stands: why incur the overhead costs of Agile if the same outcomes happen because of mismanagement anyway?

Re: Scrum disempowers developers

#320

Post by ownagefool » Wed, May 30, 2018, 6:57 PM UTC

ggregoire wrote: post #263

ownagefool wrote: post #239

Earlier quoted context omitted.

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.

Because a simple kanban doesn't have any scope/goal, it's just a disorganized TODO list. A sprint/milestone is a way to set goals for the next 2-4 weeks. At the end of the iteration, you redefine new goals according to what would bring the most values to the clients at this new moment T. If the sprint is not finished, well it's not a big deal. You move the tasks back to the backlog, or in the next sprint, or delete t…

To be fair, the simple kanban doesn't stop you from creating a scope/goal, you need to generate your TODO list somewhere, which isn't any different from sprints, but it's less rigid when it comes to the deadlines.

More to the point is, setting sprint goals is defacto pressure which many people and orginsations are poor at handling, and we can largely avoid it by not having people doing or managing the work care about end of sprints, but just that the tasks are scoped and are of a reasonble size.