4 ms·
I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the
by matthewmacleod 12y ago
I actually started writing a point-by-point response to this, but it mutated into a thousand words and will be better suited to a blog post at some point in the future.
In the meantime, I think these are generally the same shallow straw-man arguments against Scrum that we all see pretty frequently. I guess the key points to bear in mind will be:
- Scrum is not a be-all and end-all solution to all product development. If you are developing a product for a slow-moving third-party (a case which is described as one of Scrum's downfalls) then you are correct – it's probably a bad choice. So is any agile approach. That is totally fine, and I'm not sure why it's seen as a bad thing.
- Scrum is not a fully-described, cast-iron set of rules that have to be followed. It's a framework which can (and must!) be changed to suit the team, and the product that's being developed. Concerns like wider-scale management and integration of multiple projects are so dependent on the functioning of an individual organisation that it would be ineffective to have a prescriptive set of rules. Your 'Agile Coach', product owners and management team generally have to deal with these issues in other ways.
- Scrum is (apparently, based on the objections in this article) implemented poorly in many places. For example, the 'seemingly endless series of meetings'? That's explicitly one of the things that Scrum does not encourage! Micromanagement is the same. Scope change during a sprint as well. That Scrum is poorly implemented is not a reasonable criticism of it, for me.
- It's okay to fail to meet targets when delivering software, and inevitable that it will happen. Scrum provides the tools to manage and recover from those failures, and to help ensure they are limited in scope. Those retrospectives, for example – it's totally valid to say 'We committed to feature <x>, and failed to deliver it because <unforeseen dependency y> prevented us from doing so'. The important thing is to understand what caused that failure, and how similar failures can be prevented in the future. That's a fantastically powerful tool to have.
Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it.
- RalfR 12y agoI value your opinion, even if I do not agree with it. The argument of "Scrum being poorly implemented" is brought again and again. It's just another one of these go-to killer arguments. If Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly? Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it. I'd love if you'd continue the discussion over at Agile Overflow.
- einrealist 12y agoWe fail because it is about people interacting with each other. We fail, because we were trained to work on our own and competitively. We fail, because we have trouble to change our mindset and have even more trouble to change the minds of others. This is why we will fail at alternatives to Scrum, too. Scrum requires a different mindset. It requires us to work in a team with honesty and jointly in order to be successful. Teams fail at Scrum because they are dysfunctional from the start, don't share the same mindset about their work and processes or don't embrace the ideas Scrum provides.
- RalfR 12y agoIn other words: Scrum would work in Utopia?
- einrealist 12y agoDo you live in Utopia? How do you get around in your environment? Scrum is not a solution that you buy off the shelf and just run in your company. It is a framework to manage work and scope in a team. And it acknowledges that we are individuals who have to interact with each other in order to achieve success. Both aspects are equally important and have to be addressed. Scrum will not make problems disappear. But it helps you to manage them in a transparent and controlled fashion. Don't you live in an environment with rules (law) and frameworks (social culture)? Is that environment perfect? I guess not. That's why we deal with imperfections on a daily basis. Like we have to do when living Scrum.
- matthewmacleod 12y agoIf Scrum is so mega simple, why do we see endless cases of it failing to being implemented correctly? That's simple, I think: - 1. Scrum is not actually 'mega simple'. Like I said, it's a framework of outline for building a system suited to your organisation. It still requires skilled people to implement it correctly. It's like expecting coders to become magically better because they start using a framework like Rails - it might describe good practices, but it won't fix bad developers! - 2. Related to that, we see bad implementations because methodology will not fix a broken organisation. If you have bad developers or bad managers, you will not produce good products. If you hire a bad consultant, you will not produce a working Scrum implementation. Maybe we should start thinking of a framework, that people can actually implement and make successful, without requiring an entire army of coaches and consultants, who make a ton of money from it It's obviously possible to have working and efficient implementations of Scrum; I'll testify that ours is excellent, and that's mostly down to hiring a very effective Agile Coach who knows how to implement it properly. And I know we're not the only ones - I expect you'll never hear about the good implementations full of happy developers! The existence of an army of awful, unqualified consultants is a separate issue. You wouldn't expect to hire bad programmers and get good software; why would you expect good methodologies from bad consultants? Hire someone skilled and let them implement a good system, and it will work.
- sheepmullet 12y ago"Perhaps I'm just biased, because I've been working in excellently-managed agile teams that have been delivering software very effectively, and have seen how useful Scrum has been as a framework to manage the complexity of planning it." I'm lucky enough to have been in the industry before agile and scrum were popular and back before the agile days I worked on excellently managed teams that delivered great software effectively. I've also seen a lot of agile projects crash and burn. At it's core agile is a small set of guiding principles. Principals I'm sure most of us agree with. Yet it's hard to sell these principles to process heavy organisations. I've seen it fail time and time again despite the efforts of top consultants and coaches. IMO, agiles real success has been in giving structure to cowboy driven teams. Teams that now actually write requirements down. You could never convince these "cowboys" to write an SRS... But a few user stories... That's more realistic.