Why Scrum Sucks As A Software Development Practice
, published: 2014-01-24 22:29 viewed: 3947 times
Scrum based software development has been used widely in the current software industry. Despite the much hype and fanfare of scrum, it has its own pitfalls, if not used properly or over-used. Below are some of the reasons why I think scrum sucks:
1) Scrum development requires meeting all the time. This tends to reduce the actual hours programmers spent working on actual software projects. Because they are distracted with having to constantly reporting their progress. Now, how about reporting in the scrum meeting the waste of time spent on preparing for the scrum meeting??
2) The biggest problem is it takes originality out of the programmers. Now software programming is reduced into a "building construction" type of work. Software developers are forced to constantly meet the target and produce something which may or may not make sense, let alone the efficiency of the code.
So, scrum based or extreme programming based approach for software development should be used carefully. It takes time and careful engineering to make a rock solid product. Quality of code tend to be suffered in an inappropriate scrum based development. I'd say, a more cautious step is needed to evaluate whether to use scrum or not, the biggest risk is that scrum may demoralize people and make the programming work very dull!
1. JC 2010-11-03 18:11
scrum master = scramble master ;-)
3. visitor 2011-03-15 16:37
It is something totally designed for corporate thugs.
4. visitor 2011-03-28 18:51
Thanks you are right on. Hate scrum hate agile. it is just a place for sucky programmers to hide and to justify Business analyst and pm jobs.
5. visitor 2011-04-12 19:37
For big companies, yes, Scrum or extreme programming might help, but I don't see for small companies that's any helpful.
6. visitor 2011-05-03 17:12
Scrum may work for small teams who've known each other and their business for a long time, but large-scale, multi-site projects are doomed to fail with this methodology. It also fails to take psychological aspects into account (different personality types with different preferences). I don't understand how it could become such an omnipresent methodology.
7. JC 2012-10-07 12:13
What I heard from my friends working at Microsoft, Amazon, they all have some sort of agile scrum meeting on a frequent basis, and they don't like it. Now that said, probably not all groups in those companies have scrum meetings, but it seems to me more often than not.
8. ko 2012-12-13 12:49
I don't mind the meeting aspect, it doesn't cost a lot of time. But I strongly agree on the point that it takes out originality: We use Scrum and management puts a lot of pressure on keeping deadlines so a lot of crappy solutions are built just to keep the freakin' burndown chart look OK.
9. JC 2012-12-13 13:48
haha, I agree with you totally. I think software and programming is an art/craft, it is not like construction work where you just keep on piling bricks! So, a lot of times, you need to give developers decent time and proper schedule.
I am not against Scrum if it is implemented correctly, but what I've seen is that, a lot of companies just do scrum meetings for the sake of doing it.
10. jch 2013-05-26 00:11
You nailed it. Too much process takes the fun out of developing. No fun = no creativity.
11. IP 2014-01-24 04:02
I completely agree and I would add more:
3) For a planning poker to work (or any other kind of team estimates), everybody needs to know everything in that project. This causes two big issues:
* programmers continuously spent energy on being up to date with parts of the application they are not currently working on; and this violates the principles of the separation of concerns, separation of responsibilities (which are needed for divide-et-impera to actually work). The ability of working in isolation is critical in managing and solving large complex problems and the Scrum methodology is unable to allow this "work in isolation" to really happen.
* non specialized developers: everybody in the team needs to know all the used technologies (otherwise they won't be able to participate in estimating the tasks that others work on); but this prevents the team from having real experts (an expert is somebody who is spending all his energy in one direction so that he is really good in that direction). This is one of the reasons why most agile developed products that are considered successful have average quality and can't pass over that.
4) The likelihood to start implementing things before being clearly defined is very high (this is actually an non-written law of agile that happens all the time in practice).
5) Focus on execution more than on what and how needs to be done. This is the painful truth. Scrum is advertising "individuals and interactions over processes and tools", "working software over comprehensive documentation", "customer collaboration over contract negotiation", "responding to change over following a plan". The 2nd and the 4th of these mean exactly that: focus on execution more than on defining what and how to be done. And this can only help solving low to medium complexity things in a non-elaborated way.
6) Much of the work of the business analysts and managers is thrown on developers. This looks good for the business people and for management (because they are relieved from the pressure of doing most of their job), but it looks extremely frustrating for developers, who are involved in doing things they are not (and should not) be prepared for. In order to be really good, developers should focus on their technical skills only. But in Scrum, this is not possible.
7) Continuous switch between completely different activities require context switching and mindset switches. And all these are affecting both quality and productivity. The daily scrum doesn't take much time; but Scrum methodology has several other ceremonies that together take more time than the development itself. And switching your mindset continuously from learning technologies, writing code, doing business analysis, talking to the product owner and trying to convince them on different aspects, trying to convince colleague team mates in different aspects in a "self-organizing" team and so on is extremely tedious and productivity suffers very much from this process.
8) Lack of visibility: in most cases, the Scrum methodology and other Agile practices are introduced as tools to facilitate start working on something that is not yet defined.
9) Scrum matches the kind of projects that have focus on execution rather than creativity. When you want to estimate a creativity task in story points, that is obviously a bad idea. In real life, a creativity task can be solved in millions of ways, varying from the most basic quick and dirty solution to the most advanced approach that would blow up the market if it gets implemented. In waterfall, we normally adapt to the real life restrictions (such as acceptable deadlines, acceptable budget and other) and come with the best solution that match into those restrictions. In Scrum, if you just put the problem as "how much time do you need to do that?" or "estimate the size of this story", most times developers will estimate the easiest way to have that "done". And this makes a final product that can be considered "done" but which doesn't impress anybody.
10) Scrum advertises flexibility, but offers rigidity in several aspects. The length of the iteration is fixed and the same for all iterations, the size of the team should be somewhere between 5 and 7, the team members should have relatively homogeneous experience and background and should remain the same during the entire life cycle of the product development (otherwise it won't work). Ideally, these things should be adjustable from one iteration to another, depending on the needs and goals of that iteration. It is possible that in one iteration you build the skeleton of a product and have large tasks that can't be divided, while in the next iteration you may have a large amount of smaller tasks which can be split along multiple iterations and/or distributed to a larger number of developers.
11) Scrum is based on the supposition that the team members remain the same along the entire life cycle of the product. The problem is that in practice, whenever something goes wrong, people run off almost at the same time. Once that leaving trend is set, it is almost impossible to stop it. And most long-life projects that are developed with Scrum are failing in this way, because in most cases it's impossible for other teams to take on a project from some point without having comprehensive documentation.
12) Changes allowed too often and the goal of having something potentially shippable every 2 or 3 weeks causes a lot of waste. In many cases, finalizing a piece of product that has low changes to get in production causes a waste of development and testing resources. Normally, all ideas that have a low chance to get in production should be only implemented in a shallow form (proof-of-concept, design mocks, screenshots), but should not be stabilized, tested and made ready-to-ship. In Scrum, everything is meant to be made ready-to-ship, while we are aware only few things from what we do will go in prod. This causes 80% of the work to be thrown to the garbage in most cases.
13) Working without a roadmap, or with a roadmap that continuously change, causes a lot of problems that cannot be compensate later in the process.
12. Jørgen 2014-07-04 00:59
#11 is seriously the best and comprehensive comment on scrum I have ever read. it should be published in major tech papers. it is that good!