Comment by jamesrr39 | Hacker News Reader

Comment by jamesrr39 | Hacker News Reader

Parent Full thread

I found this really depends how "scrum" is implemented. Personally as a developer I like several features of scrum:

- regular retrospectives, for improving the process

- regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet)

- some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready.

- and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc.

But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks.

So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc.

YMMV (depending greatly on the setup/environment you are working in, I think)

(edit for formatting)

Scrum can only be successful if everyone is viewed and respected as peers. This is a hard requirement for scrum to be scrum. Otherwise it's just micro management.

Often neglected are the Scrum values: Commitment, Courage, Focus, Openness, and Respect. Values form a foundation for success. When agile principles are ignored and Scrum values not incorporated, Scrum (or any other methodology or set of practices) can become just a control mechanism for Taylor-istic "resource management." Scrum can be a great way for a software engineering team to and operate when they understand and apply the values and use it to self-organize, deliver regular increments of valuable software, inspect and adapt.

Otherwise known as "I like doing scrum when it's not scrum but a totally different, less onerous, process I've incorrectly identified as scrum"

If you think SCRUM (done well or at least competently) is onerous then I am afraid your not doing SCRUM properly

No true Scrumsman?

Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.

To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.

> If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.

I have a lot of sympathy for this perspective.

I also notice that 90% of everyone does everything wrong.

I don't know how to reconcile those two observations.

By admitting it is both right and wrong, and it entirely depends on the context and purpose whether one should decide it is "right" or whether it is "wrong".

Kids are using electrical plugs wrong when they stick a pointy object in it. That doesn't mean electrical plugs without child safety close to the ground aren't potential hazards.

Kids damaging their hands doing control-stick spinning minigames using a N64 controller without gloves are "doing it wrong", they could just wear gloves. Still, Nintendo lost that case, and such minigames were deemed problematic.

People browsing a website where the links turn invisible, the mouse doesn't turn into a pointer, the browser doesn't show it is loading and no loading icon is shown, are "doing it wrong" for not just waiting 10 seconds for the page to load. Despite that, UX practices rightly condemn this kind of behavior: at least add an "alive" indicator.

To some degree, you have to make things "stupid proof". That's part of this field. If for some reason, Scrum allows managers more power to micromanage, that's a potential hazard which has to be admitted. That's the problem with the "you're doing it wrong" argument. It doesn't acknowledge potential hazards. Instead, it tries to circumvent that discussion and blindly assumes that developers both can and should "just fix it" when managers are doing it wrong. There's no discussion to be had when everything goes back to "you're using the tool wrong", even if that tool is designed poorly.

What's worse, go and be the guy telling managers that Scrum should be getting them out of a job. The only people I see doing that are the people not dependent on managers, e.g. Uncle Bob and Allen Hobub, and anonymous reactions here. When you're the one who might lose their job making that statement, suddenly, suffering under misimplemented Scrum and whining about it on the internet doesn't seem so weird anymore.

The problem is often not scrum but the organization. Any organization can misuse any framework for micro management. Scrum is only successful when it empowers developers. If scrum doesn't empower you, then do something else or try to figure out what's stopping you from being empowered.

Scrum requires some premises that many businesses have problems adapting to if they've had a micro managed process before.

Scrum is, for better or worse, an all or nothing if it is to reach its full potential. Once you have "real" Scrum, you can start adapting the overall process through retrospective. But if you start your scrum adventure with "Scrum but..." then it's not going to deliver of the promises.

It is not just micromanagement, it is also the rest of the business culture. Ego-less development and placing the team over the individual can great for productivity. These productivity gains accrue to the profit of the wider company and _might_ partially flow back to the team, possibly as a bonus or possibly as promotions. However, effacing yourself for the team is unlikely to result in the kind of visibility needed for career progression and with software salaries being what they are that can mean a difference of hundreds of thousands in income over the years.

In a way, scrum and its team-based mechanics form a kind of prisoners dilemma where the first team member to claim credit will gain much more of the value generated than their peers. These incentives need to be taken into account in any framework based on teams cooperating, because they have the potential to rapidly poison any team where people are jockeying for promotion.

> it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.

The system is simple; the implementation is often shallow and ritualistic, imitating the how without understanding the why. But the way that the question was asked leaves a lot of room for interpretation. I think it is important to consider a technique as it was intended vs as it is implemented. It would be the same for TDD, or pair programming, or object-oriented design patterns, and so on.

When implemented properly, scrum is beneficial, because it makes it easier for the information to flow through the team and for the team to adjust to the reality. When implemented poorly, it is a hurdle, because it degenerates into a bunch of pointless rituals.

Which is the point I hoped I had made, In fact when I was young I worked on a project for BS5750 (aka ISO 9000) and the v senior guy at BSI mentioned that very thing to me.

The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too. What would be really interesting is a scrum variety that is easy for people to follow without losing effectiveness.

Bad scrum is like the product organization going on a diet but the product owners/managers are still addicted to eating junk food.

I like the analogy.

> The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too.

Yes, but do people then go around saying "this dieting thing is totally dumb and a complete waste of time", "I just don't get why anyone would go on a diet", etc.? And how do those who have managed to stick to a diet and think they have benefited from it look at such people? Because this is the attitude that I think I am seeing in many comments in this thread.

Scrum is not dieting, it is just a particular diet. Dieting is agile. And it turns out that Scrum, like all faddy diets, only works for a very small percentage of teams, probably due to their particular character.

That character of enjoying being micro-managed as far as I can tell.

> That character of enjoying being micro-managed as far as I can tell.

We still haven't established what is it about scrum that makes you say micromanagement. Do you regard all prescriptive statements as micromanagement? Is a software framework, such as Ruby on Rails, or Laravel, or Django micromanagement? Are code reviews micromanagement? Is version control with git micromanagement?

The difference between scrum and agile as I see it is that scrum is proscriptive enough that you can tell it doesn't work.

Agile is vague and handwavey enough that you can never really be sure that you're doing it or not. I think that was by design - a badly written rulebook won't spread as easily as a religion you can project your own hopes and dreams on to.

The best about such a process is when you have grown up above the book and can adapt it to what best suits your context.

What? It’s the opposite

He likes doing scrum when it’s actually scrum and not “scrum”

This reminds me of the only company I've worked in that attempted to adopt scrum. We almost spent more time debating about whether a particular practice was scrum or not than we did actually doing that practice.

otherwise known as "I'm not going to let Deloitte dictate the One True Method for building software and instead going to think critically about our own team".

Whether you're "Capital A-Agile" or not - following a bible down to the letter - is so completely irellevent. SCRUM is never the goal, developing software effeciently is. It's a means to an end. If you can think critically about what your team/company needs to do this, then you should.

> when it's not scrum but a totally different, less onerous, process

Can you elaborate on what in the parent comment is not part of scrum?

Have you read the manifesto? The whole point of agile is to continuously adapt the process to fit your team. Following SCRUM to the letter is exactly the thing you shouldn't do.

> Have you read the manifesto?

I'm sorry, but the basis of scrum is the scrum guide[0], not the agile manifesto. The scrum framework is fairly rigid (three roles, five events, three artifacts), and I do not remember whether it allows for much flexibility (one role instead of three, two events instead of five, two artifacts instead of three, that kind of thing).

[0] - https://scrumguides.org/scrum-guide.html

I think that standing up is actually really important!

We use it to keep things short and focused, since everyone wants to get back to their work and can not do stuff while also taking part in the daily.

Yes, this is a known trick and that's why it's used in scrum. Like you say it also helps keep things focused as people pretty much cannot do anything but listen.

A famous example of that trick is the UK's Privy Council: "Customarily the sovereign remains standing at meetings of the Privy Council, so that no other members may sit down, thereby keeping meetings short." [1]

[1] https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Ki...

> I think that standing up is actually really important!

Alas, it seems many people don't - I think I've only been at one place in the last 10 years who actually cared about keeping standups short and focused. I've been at places where standup was 20 people and took an hour every day.

Mind you, I've been at places where standup was only 5 people and still took 30+ minutes every day...

Reply on news.ycombinator.com