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.<p>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.<p>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.
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).<p>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?<p>This would eliminate the "optimizing considered harmful" point, because there is group that can work on continuous improvement.
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.<p>Now, there are some companies who DO develop like that - I'd venture to suggest they aren't the successful ones.<p>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.
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.
The article doesn't really resonate with my experiences of working with good Scrum teams.<p>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.<p>Scrum teams should be relentlessly focussed on improvement.<p>It's a deliberately minimal process which can help in of itself since everything outside of that process is open to question and change.<p>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).<p>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 <i>they are not doing Scrum by definition</i>.