Hacker News Reader

Comment by lumost | Hacker News Reader

I always grow tired reading scrum guidelines. Everyone seems to boil down to “people are overly emotional spherical cows”, simply trust the process and do your this small problem the sorting hat of scrum has chosen for you.

Anyone who’s ever been on a scrum team can tell you that engineers are not fungible unless you simplify the work to the point that you are left with awful engineers doing awful work.

Of course a Product owner will sometimes think about velocity, they might be the CTO! Or a PM struggling with a team which can’t deliver at the pace the market needs. When does a PO ever live in a world where they have oracle knowledge of value? Half the time they are fresh bschool grads working with engineers and managers with years in the company.

View on HN

The funny thing about emotional spherical cows and trusting the process is that the first rule of agile is “People and [delivered] software over process”. You can and should do anything to get working software over the line. Even if it means breaking process when it isn’t working.

And you should always prioritize people over working software, if needed.

Working on a team that groks that part is quite nice actually. You can go to your manager and say “Hey this thing is getting in my way” and they’ll say “Good god man why are you doing it then!?”

This is why I don't believe SCRUM is meaningfully agile at all, and only exists so that companies can signal agility and management consultancies can sell agility. When agile development is fundamentally about fast feedback loops and not letting bureaucracy get in the way of delivering, a process laden model like SCRUM cannot be said to meet that definition.

> "SCRUM... only exists so that companies can signal agility and management consultancies can sell agility."

many companies employ scrum that way, but it's not instrinsic to scrum. it really depends on where the locus of control is. if it's firmly outside the team, it doesn't matter which methodology you use, you're looked at as cogs in the machine, as order takers. the locus needs to be in, or at the very least, right next to, the team for any kind of agile development to work. it's usually top-down hierarchy that causes that kind of friction and expectation mismatch.

But if the team has the impetus to change the processes, they can get rid of the SCRUM rituals that don't work for them. Given that it comes with quite a few, bottom up SCRUM will inevitably change into an actual agile system suited to the team.

I've never worked in a team (or run a team) where SCRUM was kept wholesale by the team or anything other than SCRUM sprints were chosen by management.

Nothing is really meaningfully agile because "agile" isnt really a meaningful thing. It's something everyone projects their desires onto.

Fast feedback loops were never part of the core stated values.

That's just not true. See here: https://agilemanifesto.org/principles.html

All of these statements are about optimising the development feedback loop:

> early and continuous delivery of valuable software.

> Welcome changing requirements, even late in

> Agile processes harness change for the customer's competitive advantage.

> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

> At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Feedback isnt mentioned. Loops arent mentioned.

I do appreciate that your interpretation is one possible interpretation of the above but it isnt the only one.

You can also interpret it as develop as fast as possible, avoiding any kind of development guardrails, keeping no docs and being ok with 150 page requirements word documents that will become outdated tomorrow.

I wish this were me being disingenuous in interpretation but IME it's not all that uncommon.

rapid responsive change to changing requirements implicitly requires a tight feedback loop.

Sustainably, yes. Ive seen it mean cut corners and a rapid build up in technical debt just as if not more often. The agile principles now stick in my craw as a result.

I kind of wish agile DID emphasize feedback loops but it doesnt. A set of principles that waggle their eyes and hints suggestively at feedback loops isnt good enough IMHO.

Yes, that does happen, but the agile manifesto addresses sustainability too:

> Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Agile development is massively misinterpreted, but this is on purpose. Actual agile development promotes bottom-up structure and rejects the types of process that generate metrics that corporate types can use to maintain control. Thus it will never appear in its real form in enterprise companies. Cybernetic organisation is inherently anti-authoritarian, and corporations are inherently authoritarian, so this is an inevitable and largely insurmountable conflict. I'm honestly surprised that Toyota was willing and able to implement lean manufacturing, agile development's predecessor, given it places trust and authority in the hands of factory workers.

>Agile development is massively misinterpreted, but this is on purpose

I dont believe it is. It's just a result of its intrinsic vagueness and everybody integrating it into their belief systems.

Furthermore, I think it was left deliberately vague enough to allow people from the CEO down to the lowliest programmer project their (potentially conflicting) desires on to it because thats how you drum up consulting business.

>Actual agile development promotes bottom-up structure and rejects the types of process that generate metrics that corporate types can use to maintain control.

You could argue that people over process means that but as with all agile principles it's not the only valid interpretation.

It's also the opposite of what scrum does but...apparently most people agree thats agile?

Dont get me wrong i think your view of what agile "should be" and mine are closely aligned I just think it needs its own name "x" to avoid all the baggage (e.g. it should not be possible to consider scrum "x").

Changing the name of things will not prevent the process of recuperation, which is what I'm saying happened to the concept of agile. Any idea can be "reinterpreted" to remove its more radical parts. I mean hell, cybernetics itself has been recuperated into management consulting since the 80s, hence all the references to synergy and portmanteau words like imaginnovation or whatever - and cybernetics are at the core of the type of "agile" we both approve of. There is no convincing CEOs with words to hand power over to employees, regardless of whether it improves productivity or not.

I am sure they are out there, but I have never met a “balanced” full stack engineer, unless they were equally bad at all levels.

As a full stack engineer, I too am surprised at how hard it is for people to straddle both. I think that only came about for me, from building my own projects end to end.

people have different strengths and perspectives (the non-sphericalness of real people) so it's not surprising that folks gravitate towards an area of strength/interest even if they can functionally work on the 'full stack'. as a 'full stack' dabbler[0], i enjoy the view layer stuff the most, but not so much with the js-dominant frontends of current fashion. for that reason, i'm really digging hotwire as a retro-futurist take on server-side-rendered-but-reactive web dev (along with cousins like livewire & htmx).

[0]: product manager who likes to make stuff, in my case

Yeah, I would consider myself full stack, but when it comes to css I definitely tweak and pray like a hobbyist, not a professional. I can change and implement front end as maintenance or evolution, but God help me if I start in greenfield front ends.

> Everyone seems to boil down to...simply trust the process

In older days business would say what they wanted, engineering would give a time estimate, and then we get to work with a deadline both commit to - the waterfall method.

With scrum, business says what they want when they want (although preferably at the beginning of a quarter), but no real estimates are done and thus no deadlines, work comes in and is prioritized. This entails the micromanagement of daily standups, stories needing to be broken into bite-sized sprint length segments etc.

Except we still wind up with deadlines, sometimes not even communicated until the team is into the work already. So it is the worst of all worlds - engineering gives no estimates, micromanagement of daily standups and features needing to be broken into small sprint length problems, plus, what was supposed to go away but has not - deadlines - not estimated by engineering, but handed down as fiat from somewhere in management. This might not be "real scrum", but it is how it works in more than one company that is supposedly working in the agile/scrum method.

Right, that’s not scrum. That’s picking aspects of it, doing them wrong, and calling it scrum. Just because that’s what many business chose to do doesn’t mean that it has no value of done “right”. For example, standup is not a “prove that you got something done yesterday” meeting, it’s about making a plan for the day. Many businesses treat as such, but that’s just wrong. And toxic.

Agreed. The issue I've frequently run into is business side thinking "we need all this, and by this date". Then trying to apply "agile" on top of this assumption. It never works out with that mindset.

Reply on news.ycombinator.com