Scrum Thinks People Are Stupid | Hacker News Reader

Scrum Thinks People Are Stupid

nih.blogspot.com.es

16 pointsrizumu17 comments

There's a lot to take offense to in this article and I wonder if the author has any practical experience with working within agile constraints or if he just picked up a book and didn't like it. For example, "In theory, developers are supposed to be interchangeable in agile/scrum". I've never seen that articulated in any agile literature. To the contrary, the agile manifesto puts "individuals and interactions" on, literally, its first line. It's ALL about people and finding ways for people to contribute to delivering working software.

Processes at their best are self-imposed sets of constraints that are empirically found to lead to better software (for whatever axes of 'better' makes sense for your team - faster, feature richer, higher quality, etc.) Scrum gives you a baseline set of rules to abide by. Any team who've worked with Scrum for more than a few months will start to tweak, add to or remove from these rules. If they're any good, they'll measure their tweaking and see what works and what doesn't. This is the whole point of having a retrospective.

As another example, if you want to include quantifiable performance bounds in your stories, do so. We work Scrum-ish, and we have a set of QA steps for every story implicit in its delivery (works across supported browsers, feels fast, immune to common security errors, etc). We test for this, and we demo it, but it's not articulated in every story. It's implicit in our work.

If they weren't able to adjust their rules to become effective before they adopted scrum, why should they be able to do so afterwards?

Who are 'they'? It might be that teams come from a more rigorous environment with project plans and imposed rules and were never given the chance to experiment with how they create software, or they might come from an environment without any rules whatsoever. Both work for a lot of companies, but usually you try something like Scrum because they don't.

A lot of times it requires a change of mindset where managers and executives have to relinquish control and trust developers to do what's right. That might not be the easiest thing in the world.

I'm not a hardcore scrum proponent, but "Scrum compensates for lack of X, and hence works less well for people who have X" is not necessarily true. Being able to swap the product backlog can help correct planning errors, but it doesn't make planning skills obsolete. What it does, though, is to assign an exact responsability for planning errors (sunken costs through unneeded functionality are the product owner's fault, changes in plans that are not realized yet are not realized).

Many important things in a Scrum process can be achieved through the definition of what is "done". If you know for sure what parts need to be optimized, then optimizing them may be part of getting them "done". If you don't, then there is no point in pointlessly optimizing the whole system where only a fraction of these optimizations will be useful and the rest of them just make the code less readable.

I am beginning to think that even small teams should be split in two groups: feature and maintenance (even if this means a 3person/1person split). I often see the need for internal tooling and polishing that is never met, because there is no one assigned to it, everyone has to build features. Scrum is a great tool for feature-driven development. Kanban is a great tool for continuous tasks. Why not have one team doing Scrum for features and one Kanban for maintenance? I often see that split in companies that have developers and a separate admin group, why not do that for developers internally?

This would eliminate the "optimizing considered harmful" point, because there is group that can work on continuous improvement.

One place I worked had an explicit 30% dev time for internal improvement. It wasn't Agile, but cleanup work did supposedly get scheduled.

I'm imagining that will cause unpleasant friction between the two.

The Feature group get all the credit and are heroes for solving things quickly, while the Maintenance group have to clean up their bloody mess without getting any recognition.

I think thats a problem in general. I've seen companies where the admin team was highly regarded, although all they did was (good) maintenance work. But they were also good in talking about this in a way of "this and that got better _in general_ because, over the last weeks, we worked on improving this and that". The idea of actually naming the people that have to do maintenance also gives them the possibility of talking about it in context of their work.

"I am beginning to think that even small teams should be split in two groups: feature and maintenance"

Noooooooooooooooooo! :-)

Seriously though - I'd go as far as saying that it's an organisational anti-pattern. Every time I've seen folk do this it's gone terribly wrong. Some of the behaviours it seems to encourage:

* The feature team no longer get to deal with the messes they produce - the maintenance team does. So the feature team suffers a pressure to not worry about those issues so much, which leads to worse code getting released.

* The maintenance team gets seen as being less important than the feature team, so product maintenance gets neglected.

* You waste a lot of time in pointless arguments over whether something is a feature of maintenance. The distinction often ends up actually being fun vs not-fun.

* Feature development is perceived as being "harder" than maintenance - so all of the best coders end up in the feature team

* Once the previous point gets into play and you have the "good" devs on the feature team and the "bad" devs on the maintenance team you suddenly get being assigned to the latter as a being seen as an insult/punishment (in one particularly egregious case I saw being assigned to the maintenance team being actually used as a punishment! Gack!)

Seriously - total suckage. Don't go there.

(Also curious to know why you don't think a kanban approach is a good one for feature development - since I use it that way myself, and know a bunch of other folk who have that approach too.)

Totally agree. The whole Agile farce is about treating programmers as idiots who'll end up putting a flight simulator in your spreadsheet unless you nail them to a task card, and program managers as drooling morons who spin a wheel of fortune to pick the direction.

Now, there are some companies who DO develop like that - I'd venture to suggest they aren't the successful ones.

Hire better developers, hire better managers, incentivise the lot of them to care about the thing they're building. Ditch the Agile crap, it's about minimising the damage incompetent people can do to your project, while compromising the best people until they too are just mediocre.

Not to be confrontational, but I'd wager that you've never developed in an agile context for any longer period of time?

The last 7-odd years in my 20 year career, 50 (very smart) people, multiple teams. Long enough to watch it spread through a company, with the attendant disruption, only to be revised away as the realisation set in that, like so many silver bullets, it was only nickel-plated at best.

Now I'm watching as another 'Agile' team pushes 6x4 cards around (at least they've managed to adopt a half-assed electronic version of that). Sadly there's no methodology that'll save them, but that's a different problem.

Then I don't get the hostility displayed in your original comment. Of course it's not a silver bullet, it's a set of tools for managing development together with a philosophy of work.

YMMV but we've used several agile ideas (for example iterations, retrospectives, stop-the-line) to great effect to reign in scope creep, increase quality, reduce overtime and make people happier, overall.

The thrust of this article seems to be that Scrum is designed to work in the real world, rather than in a made up utopia the author admits doesn't exist. Great.

I think the authors argument is not that Scrum isn't better than many other approaches, just that it may have the downside of limiting further process development when teams are healthy.

The article doesn't really resonate with my experiences of working with good Scrum teams.

It does, however, sound very much like some organisations I've been involved with who have adopted one or two of the Scrum practices, but haven't really understood the core of the process.

Scrum teams should be relentlessly focussed on improvement.

It's a deliberately minimal process which can help in of itself since everything outside of that process is open to question and change.

Even ignoring that of the five regularly scheduled events in Scrum two, arguably three, are specifically focussed on self-assessment and improvement (Sprint Review and Sprint Retrospective are the definite ones. I'd also argue for the Daily Standup/Scrum because of the focus on obstacles in the way of progress).

Now there are certainly criticisms that I have of Scrum - but thinking folk are stupid and not fixing problems are very definitely not on the list. If a team does not focus on improving their process every sprint then they are not doing Scrum by definition.

Then Scrum is smart.

Reply on news.ycombinator.com