This is a bad article. It conflates "bad management" with "bad process", and unfortunately pays too much attention to an idealised "official" version of Scrum.

This is a bad article. It conflates "bad management" with "bad process", and unfortunately pays too much attention to an idealised "official" version of Scrum. This is the first thing that anybody developing a Scrum process should discard. Let's deal with these points step-by-step. Because all product decision authority rests with the “Product Owner”, Scrum disallows engineers from making any product decisions and reduces them to grovelling to product management for any level of inclusion in product direction. This is a sign of a bad team. The product owner in a functioning Scrum team works with the engineers to establish the product direction, both at the micro and macro levels. My current product owner will involve the engineers in almost all product decisions; she is responsible for mediating between the different priorities set by different parts of the business. All product meetings are open to engineers who want to contribute. It works well, and Scrum has no embargo on this. Scrum, in accounting for all the engineer’s time in a tightly managed fashion, discourages innovation — which typically occurs spontaneously and outside of any schedule or system of good predictability. Scrum should not involve 'accounting for time'. It's entirely possible to include innovation and research within a sprint – sprints should always be a little flexible and allow for some expansion or contraction of goals specifically to support this. Longer-term innovative or research tasks should be treated like any other work – and importantly, the process should be flexible enough to accept that priorities sometimes change, and that failing to meet a sprint target because the situation changed is okay. 3. Scrum encourages “least amount of work possible” solutions — to conform to it’s strict predictability requirements. This is simply false. Uncertainty should be built into every prediction made. The goal is to assist with predictability, not to require it. By dividing every task into small items that can theoretically be completed by anyone on the team, Scrum discourages engineers from taking pride in and/or ownership of their work. Only if you have a poorly-skilled or unprofessional development team. Scrum isn't going to fix that problem. 5. Scrum is highly intolerant to modification, and it’s proponents typically espouse an all or nothing attitude in it’s implementation. Finally, a possible reasonable objection! The first thing one should learn to do when building a process is to ignore all dogma. Adapt Scrum for your particular requirements; it's still Scrum, more of less. Nobody has ever implemented Scrum precisely as described. 6. Scrum’s attitude of intolerance to self-examination is present in all of it’s practices. Only processes that operate internally to Scrum’s framework are open for modification— as for Scrum itself, it is seen as sacrosanct. See above. 7. Scrum is very management heavy. Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more. Scrum involves three roles – a product owner, a scrum master, and a development team. The product owner decides what to do; the scrum master looks after the process and removes roadblocks for the others; the development team do the work. These roles can be combined where required. Frankly I'm struggling to imagine a lighter form of management. Scrum is typically implemented with HORRIBLE task management tools (Jira, tfs, etc…) that enforce very bureaucratic interpretations of Scrum that waste huge amounts of developer time. Additionally, they effectively lock you into one mode of operation, no matter how ineffective. You're entirely free to practice Scrum using whatever tools you want. Personally I have no problem with a simple Jira implementation. If it's been over-complicated, then you have implemented it badly. The whole point is to provide tools that make it easier to manage work. I use Jira, spend essentially no time using it beyond keeping track of what I'm doing and sharing knowledge about particular work. If this tool doesn't work, use something else. 9. Scrum discourages bug fixing, reduction of technical debt, and risk taking, all because of its narrow, exclusive focus on only doing items that Product Owners would interpret as valuable. The product owner must be a skilled professional who works with the development team to decide what the priorities are. If the development team believe that a particular bit of non-user-facing technical work needs to be done, then that should be taken into account by the product owner—who as a professional, will trust the development team's judgement—and appropriately prioritised. No process will fix an overworked team, or compensate for a lazy product owner. Frankly, it's not Scrum's fault. 10. Scrum is hypocritical. Do managers or Product Owners track and estimate every task they engage in with little or no say in what they work on? Are they required to present burn down charts that show that they are on target to finish? Are they required to do bi-weekly sell-off meeting to justify their activities? Product owners are accountable for their activities like anybody else. I think they'd benefit from a bit of Scrum in that! In fact, we've found that our process has worked well enough that other business units are beginning to roll out Jira to help teams understand what work they're doing. As for the other points, I've never had to present a 'burn down chart' or otherwise justify my activities to anybody. Again, Scrum will not fix a micromanagement culture. It assumes that engineers do not have task tracking systems that they already use to manage their time and therefore need time-management hand-holding. Scrum does not involve time-management. Let me say this again: "SCRUM DOES NOT INVOLVE TIME-MANAGEMENT". It assumes that engineers are not to be trusted with directing their own work. It does not do this. I am trusted to direct my own work. I agree what that work is with other stakeholders. That's Scrum. It assumes that engineers cannot align themselves with the best interest of the organization, without tight supervision. It does not do this. I am not supervised; I use Scrum to agree with the rest of the organisation what is in its best interests. It assumes that engineers cannot conduct a meeting effectively without a facilitator It does not do this. My scrum master (actually the head of development, acting in that role for multiple teams) takes care of the nitty-gritty of booking meeting rooms, setting calendar dates, preparing documentation, taking notes, finding availability, and that kind of thing. They are a helpful facilitator. If you have an alternative, that's awesome. The scrum master doesn't ned to be involved. It assumes that you can plan every facet of a software task by merely talking about it in sprint planning/backlog grooming It does not. No ticket describes every aspect of a feature. Ideally, you can do this, but we all know that things can change. Roll with it and take the obvious step of dealing with unexpected changes like an adult. It assumes that all engineers work the same way. That's just flat-out wrong. Scrum story points are supposedly meaningless, yet they are tracked, recorded and presented at many levels in an organization and often are the only metric by which a team’s performance is represented (ie. Velocity) As far as I'm aware, nobody outside my team knows anything about our velocity. It's purely a method used to help us understand how much work we can commit to in a given period. If it is being reported, you are doing it wrong. Scrum is designed to manage the weakest Engineers and consequently dis-empowers the better ones. No. Scrum is the opposite of many of the points set forth in the original agile manifesto: No justification is provided. 15. Scrum ignores the fact that any task that has been done before in software does not need to be redone because it can be easily copied and reused. So, by definition, new software tasks are truly new territory and therefore very hard to estimate. This is laughably wrong. Basically, I disagree emphatically with every single point made in this article. I have had an excellent time as part of a Scrum team; I have a clear idea of: - What I'm doing - What others are doing - How we can help each other - What the business priorities are - When particular tasks take longer than expected - How we can avoid surprises and failures I honestly can't imagine working any other way.