# Why Non-Constructive Scrum Criticism Should Basically Just Die Giles Bowkett has mastered opposition, but he's not yet ready for government. In [this post](http://gilesbowkett.blogspot.com.au/2014/09/why-scrum-should-basically-just-die-in.html) he tells us Scrum is "conceptually flawed", "bizarre", "condescending" and at best, a "dog-and-pony show". But his only positive prescription, other than "get better at hiring engineers" (gee, I'd never have thought to try that), is the folksy wisdom that we should "treat these workers as adults and trust them to do their jobs." You don't want to do that, and they don't want that either. If you tear down Scrum and don't replace it with anything, your developers will refactor the same code as each other and spend days sorting out the merge. Then they'll find out that no-one actually wanted the feature they were working on anyway, and they've wasted the last few weeks. Then they'll realize they have no idea what they're doing, or what anyone else is doing, and that the company isn't making anything anyway because it never does the things that could make it money because noone tells the lowly developers what those things are. And then they'll quit. Estimating and planning with stakeholders puts the business value front-and-center - and what the business values can often surprise you. I was once on a team that received a cake from another office expressing their heartfelt gratitude for a two-line change that, had we any idea of the value placed on it, we could have made at any point in the previous six months. They'd assumed it would be months of work, so they never considered it high-priority enough to ask for (we only found out about it at all thanks to a company-wide drinking event, but that's another story...). Some developers know and understand the business, and they should be treasured. But even the best such developer is unlikely to understand a business role as well as someone dedicated to that role - jack of all trades and all that. Making effective use of dedicated developers will make hiring easier and your business more productive than if everyone has to be capable of wearing every hat (and that's not to say you shouldn't encourage growth in that direction). So you absolutely *should* assume that developers aren't business people - not because there's no such thing as a businessy developer, but because *your process needs to work for developers who aren't businessy*. One thing your team of (potentially) nonbusinessy developers and nontechnical businesspeople sometimes needs to do is make decisions that have both technical and business consequences. And as any economist will tell you,the best way for people with different information to reach a consensus is an auction. "I want this feature." "Ok, it'll cost you this." "That's too much. What about if I remove this requirement?" Numerical estimates immediately nudge the dialogue in a productive direction. It's the difference between "no, because" and "yes, if". When the business side asks for a feature, it's all too easy to respond "are you insane? We'd have to refrobnicate the buzzwitzer and defrob the lillicator". Telling them "we can start on that, but it will take three developers and one sysadmin two weeks to do just requirements a) and c)" is infinitely more helpful. After all, occasionally it really is worth spending those two weeks - but that decision can only be made with the benefit of both people's knowledge. Simply allowing business to tell engineering what to do goes just as badly as having tech decide everything for themselves. I've seen Scrum-style estimation work and work well. At my first job we had a simple solution to disputes over estimates: it's called the "you do it then". In fact the planning meeting worked as an auction on a second level: developers who were the "low bidder" on a particular story, because they were more familiar with that area of the code or enjoyed that style of programming more, would generally take that story. If someone already had two weeks' worth of work, we felt free to ignore their lowball estimates. Similarly, the whole reason estimates are expressed in abstract points (rather than, say, man-days) precisely to prevent managers doing something silly with them. Evidently in Bowkett's case this wasn't enough, but again: positive suggestions are constructive, just throwing the whole thing away isn't. And at some point you have to be the change you want to see in the world: if a manager says you can't leave yet because your velocity this week is too low, do what I do. Tell him to fuck off. Scrum-style estimation is not just good for the company, it's good for developers too. The most vital part of job satisfaction is the feeling that one is doing something valuable, something that other people want. For an ivory-tower backend programmer like me, who spent today switching our monad stack so that some other programmers would get better error messages, you can sometimes feel like a lighthouse keeper in the post-apocalypse, unsure whether the ships you're warning are even out there any more. Business requirements can sometimes feel perverse - and sometimes that means you've misunderstood them, and sometimes it doesn't. A planning meeting where you can ask for clarification from the person who actually wants the feature is the easiest way I've found to resolve this. The rest of Bowkett's attack is focused on standups - or rather, on standups where managers sat down. That's not even bathwater, that's, like, the mold that's grown in your bath. But Bowkett is still determined to throw the baby out with it. Never mind that you could, like, tell the manager to stand up. Or sit down yourself. Async-only development by distributed teams may work in some cases, but to claim it as a panacea is... questionable, to say the least. Bowkett is right that open-source distributed development produces higher-quality code than most software projects. But *Agile isn't about producing high-quality code, it's about delivering business value*. I've contributed to open source, and all the problems Agile advocates would predict are real. I've seen patch queues accumulate for years with features that users desperately needed, but the maintainer wasn't interested in adding them. I've seen people have to throw away a branch with a valuable feature because the underlying code was refactored at the same time. I've seen 3/4 of a codebase dedicated to LDS ordinance support because the maintainer was an LDS member and that's what he cared about. I've seen beautiful, beautiful code that had become an end in itself, while the product atrophied to the point of unusability. These problems aren't insoluble, but they need actual solutions, not handwaves. Daily standups have worked shockingly well in every company I've ever worked for that used them. In fact they're so valuable I'm thinking of switching to twice-daily standups. If you're a distributed business then you don't have that option; in that case all I can say is good luck, and may the best business model win. Notice how Bowkett's two standupless success stories - Github and Basecamp - are both software for developers. If you're developing fishing software, and everyone on your team is a super-keen, dedicated fisherman, you probably don't need Scrum. You probably don't even need Agile in any flavour. Likewise, if you're developing *software for software developers*, you don't need Scrum. But most of us are working in different niches, on things we don't understand as well as we understand software development. Most of us are working on teams of average developers. We need input from domain experts. We need to co-ordinate with each other. I've worked on companies that used Scrum, and companies that didn't, and companies that pretended they used Scrum but didn't[1]. Scrum is far from perfect; indeed there are specific changes I'd make to a pure-Scrum process (e.g. using Kanban-style flow with ad-hoc planning meetings rather than fixed sprints). But the correct response is not to tear it all down. If parts of Scrum aren't working for you, think of possible improvements; try them, and see if they work. Iterate. After all, that's the Agile way. <br /> <p /> <br /> [1] In fact I've even worked for a company that pretended it didn't use Scrum, but did, though I only realised this afterwards. (P.S. Of course in sustainable development you have a backlog on day 1. Your development process needs to work when you have a backlog; that's what makes it sustainable. So why not use it from day 1? I'll admit that "sprint" is a super-dumb term though) [Home](/) <div id="disqus_thread"></div> comments powered by Disqus