Why Scrum will never work

July 13, 2011 at 11:22 am | Posted in Agile, Programming | 73 Comments

With such a slightly provocative title I will probably have to start with the disclaimer first: what is written here is my own opinion and not necessarily that of my employer. That is, if I still have one after posting this blog. What’s more: I’m a big fan of Scrum and other Agile methods. It pays my bills. Uh wait, let me rephrase that a bit more accurate: I’m totally 100 % convinced that Scrum works for software development.

Now with these formalities behind me let’s get a bit more serious: I really like Scrum. I have been using it for the last 5 years, I haven given several presentations about (distributed) Scrum at several conferences, I’ve written an article about it together with Scrum guru Jeff Sutherland, etc. However now that the Agile Manifesto is 10 years old I thought it would be fun to put on Edward de Bono‘s black hat and explain why Scrum is never ever going to work.

Reason 1: the cornerstone of Scrum is about trusting people. Creating a safe environment so that we can be open to each other, learn from our mistakes. And all that other touchy-feely hippy back to the 60’s stuff. That is not going to work! Did you notice my disclaimer when I started this blog? I had to put it there because quite a few people read my blog, including customers and my boss. There are a lot of pointy haired bosses out there (oh no, another disclaimer: by boss isn’t one, he is a nice friendly guy, bla bla bla). This world is full of alpha males (and females?) who are not at the least interested in you, your process, the outcome, etc. Being open is only going to hurt your career. Room for mistakes, taking risks? Don’t be naive!

Reason 2: according to Scrum ‘people do the best they can’ if you give them enough freedom. What the hell is this based upon? They don’t. They will probably do the least they can because in general most software developers are underpaid, especially compared to their managers. That’s why they want to become managers or software architects as soon as possible, since they can then still be lazy without anyone noticing and the added bonus that they are getting better paid.

Reason 3: because of the previous reason we still have to put project management on top of Scrum teams, so at least it has some output. So this is probably going to be business as usual. Assigning tasks to team members, micromanaging developers, demanding progress reports, etc. All the usual actions to slow your team down as much as possible.

Reason 4: Scrum is just a process. I have seen many processes (like CMM which is nowadays called CMMI) and I have seen them all fail and leave a lot of frustrated people behind. So if you are stuck (like most companies) with a bunch of average people then nothing is going to change. Scrum doesn’t improve your software, good people do! And by definition, you don’t have those good people since you just have Joe Average (or worse) as a programmer because your company doesn’t want to pay a decent salary.

Reason 5: Scrum delivers ‘business value’. Well no, actually it doesn’t. For many reasons. The guys or girls that know about business are not going to be involved in your project. They like to lunch with customers, not work on this weird thing called backlog to explain a bunch of introvert nerdy software developers what to do. So your team ends up with a junior help desk employee as a product owner. And besides, your whole ICT department is a cost center anyhow. So don’t start about business value.

Reason 6: an Agile team is supposed to continuously improve. That is why Scrum has retrospectives to see what went well, what can be improved and to define actions. Now do you really think people want to improve? First they have to think of possible improvement actions. Next they may even have to execute them, which might well take them way out of their comfort zone. People resist change, and therefor improvements. Your old working habits may suck, but at least they kinda work and it gets you through the day.

Reason 7: the Product Owner focusses on the ‘what’ and ‘why’ questions, the development team decides ‘how’. Nicely separated so the team can go for quality and thus high velocity on the long term. However, this is not going to work. Your product owner wants this functionality right now and doesn’t care the least about software quality. Just deliver those features as fast as possible because there always is a deadline, promises made to this important customer, etc. And don’t think you can blow away this junior product owner, because behind him is this business manager ranked high in the companies hierarchy. You as a developer are just part of a cost center and probably going to be outsourced soon anyhow. Now how is that for motivation and trust?

Reason 8: my previous point was about quality. There is some evidence that pushing productivity lowers the quality of software. On the other hand, when you focus on quality, you will get higher productivity. However Joe Average programmer doesn’t care about software quality. If the quality is poor, developing some piece of software takes more time, but why care? He is getting paid between 9 and 5. The project manager (or Scrummaster!) will take the blame for missed schedules. Even worse, if this developer is hired from another company it is in his (and his company’s) interest to stay as long as possible. So this all means that your productivity in Scrum isn’t going to be the least bit higher than with any other method.

Reason 9: “yes, but if we only build the necessary features, then at least we will have a lower total cost, right?” It never stops to amaze me how naive people are when they say something like that. You don’t build necessary features. Most of the time you are on a fixed-price contract for a major banking or insurance company. Or even worse: a government contract. They have selected you because you offered the cheapest bid (which is pretty naive in itself) but they are going to make sure that you will deliver all the requirements they have stated up-front. Of course at least 50 % of these requirements have no business value at all, but hey, you aren’t going to fool the project manager that handles the project from the customer side. He is an alpha male and you are going to deliver that last bloody feature as well!

Wow, wearing that black hat was even more fun than I thought! Must…. take…. it…. off.. now…

73 Comments »

RSS feed for comments on this post. TrackBack URI

  1. Absolutely hilarious post. Most likely all of us have heard these similar reasoning before and will hear them also in the future. Smiled all the way from the beginning to the end, though temporarily felt little depressed along the way as it almost sounded convincing.

  2. “Being open is only going to hurt your career.”

    Did you really want to say that ? If yes, then I guess I’m glad I don’t work with you !!

    Regards

    • Please read the disclaimer carefully (again): the whole point of wearing de Bono’s black hat is to be as negative as possible and try to find all the holes in an idea. So this is a ‘theoretical’ exercise. These are not necessarily my own beliefs in a similar way that an actor is not the same person as the role he plays in a movie.

    • Whahahahaha!

  3. “You as a developer are just part of a cost center and probably going to be outsourced soon anyhow. Now how is that for motivation and trust?”

    scary true

  4. Brilliant post. Evil thing that hat. Right through the cynicism I must admit I felt rather more truth to your post than I would like. It made me laugh as much as it made me think. Again, brilliant post.

  5. […] Why Scrum will never work « Maurits thinks aloud. 0 […]

  6. Really great Maurits! I wish many non-Agile people would read this.

  7. Very nice blog Maurits.
    Balaji D Loganathan

  8. It can work very well in startup or companies whose CEO is acting as Super Product Owner like Apple. In tradditional corporate organizations where the Peter Principle has widely spread it will be very hard. So Scrum and Agile needs to get out of IT if she wants to really be durable see my post http://lepinekong.com/my-personal-encounter-with-demings-teaching-and-what-i-told-to-jeff-sutherland/

  9. CMM is not a “process”, it’s a modelling tool. In fact it’s a great indication of a *broken* process (and therefore a broken organization) to see a claim of following “the CMM process”; it’s clear evidence that somebody failed to get the basic idea.

  10. This is great! I love the ranting and tangents then coming back to a new point. Smiles all the way through.

    I’ve gotta agree — Scrum does not guarantee success. I think of it as a tool in management’s pocket. And yes, there NEEDS to be management. (Trust me, it sucks when there is not.) But I find that daily accountability tends to help the lazy developers be less lazy, or “sucky”.

  11. ho hum, such a tired cliche for developers to slam process. stems from a general aversion to actually have to deal with ….gasp!…humans. lemme guess: everyone is an idiot but you, you’re the type who never maintains other people’s code, you just HAVE to rewrite because the guy who coded before you was SUCH an fking idiot! yeah yeah, i know your type. if you actually think CMMi does not work then try explaining the almost perfect success of a project called MACS led by the Red Cross. Go donate blood and see if you get HEP-C accidentally because some anti-process “hero” programmer like you had an off day while putting code directly into prod. cos believe me they would not have put up with your sophomoric b.s. for 2 seconds

  12. “Reason 1: the cornerstone of Scrum is about trusting people.”

    The cornerstone of all business is about trusting people. True, you could look at Wall Street today and say that “business will never work”, and you might have a point, but I think that means, at worst, that Scrum is no worse than any other way to run a business. :-)

    “Reason 4: Scrum is just a process. I have seen many processes (like CMM which is nowadays called CMMI) and I have seen them all fail and leave a lot of frustrated people behind.”

    I wouldn’t compare to agile processes to CMM/CMMI just because they’re both “process”. I worked at a megacompany that tried to implement CMM/CMMI while I was there, and I attended classes for months and I still have no idea what CMM/CMMI are or what they’re supposed to do or how they’re supposed to help me or the product or the company. Dijkstra once observed that “simplicity is prerequisite for reliability”, and if some development process makes organic chemistry look easy, then it’s completely doomed. That’s not to say that Scrum will necessarily succeed — simplicity is necessary but not sufficient — but at least it isn’t an inherent failure like methodologies that no human can understand.

  13. I am curious; is there actually some peer reviewed study that shows productivity gains using Scrum — or any agile methodology for that matter — or is it the software equivalent of six sigma?

  14. This guy writes a provocative blog posting title then spends the first paragraph back-pedalling. Kind of like 90% of software blog posts these days. Why is there so much of this bs on the web? This article isn’t any more egregious than the other crap, so don’t take it personally, but I wish facebook made a hate button.

    • I bet this was your reaction when you discovered that ‘Santa Claus does not exist’!

  15. Cool :) I turned a bit sarcastic but I think it is ok. I wish you that you keep fighting :)

  16. I have often played with the Black Hat idea for an “Anti-Scrum” as a joke conference session… when I started doing the work, creating this evil mirror image of Scrum, I realised that the “dark side of the force” was at work. This stuff would appeal to lots of people. Lots of horrible people. And it would make nice people who used it.. horrible.

    So I saved it to a remote corner of my HD (Alongside the scans of receipts from 2006, old performance reviews and 400 page design docs) to never see the light again.

    One day I may out it… but some things shouldn’t be known by mortal men.

    “When you stare into the Abyss, the abyss stares into you.”

    Nigel

  17. Apparently, SCRUM is made for cooperative and not corporative environments :) Unfortunately, we live in the corporate world…

  18. I enjoyed the post, thank you! It seemed to me that there was an underlying theme on Joe Average. I think scrum (really all agile methodologies) is different from other processes in that it works great with great individuals and potentially crappy or horribly with the incorrect individuals. It definitely puts a lot more control in the hands of the individuals on the team. Most “old school” methodologies are about leveling the field, getting the same output from a team no matter who the individuals are. So, if you have a great team with great individuals, the “old school” processes are actually hindering you. My experience with most large scale enterprises that treat development as a cost center is that they are okay with Joe Average and want the same output, so there is a decent chance they may get better output from an “old school” process than an agile process. However, if you have an organization that hires great individuals and really empowers them with an agile process like scrum, your results will be amazing!

  19. I work for government in Brazil, and here gov. employees never get fired, no matter how lazy or irresponsible they could be. No matter what they do, they will get paid at the end of the month. And that is a big barrier to implement any agile way of work. Your post just summarize what I live every day in my work.

  20. Funniest, most spot on article I’ve ever read on When Scrum Met Reality. This comment good for one mutual cry in a beer, I’ll buy the first round.

  21. I didn’t laugh much… I think you’re post is about the wrong people, not the wrong process. You’re basically bringing up the worst case scenario and in that case it will fail, wether using scrum or not. But I have to agree with the trust part. Management doesn’t trust anyone and continuously asks for status along with always being promoting the idea that teams are free to innovate but never giving the room for it.

  22. I …. like … your …. last …. sentence :D

  23. “The guys or girls that know about business are not going to be involved in your project. They like to lunch with customers,”

    So much true! At our place as well, we only get interns… if we lucky. Intern sits at Scrum planning meeting for little thing, does some nodding when discussed is requirements, then intern leaves. We no more see intern.

    Then manager asks: what do developers think needs doing? And rest planning is done by developers who know software system and know about things needed doing. Nice for developers? Maybe! But not really Scrum Way.

    Product owner helping with scrum? Don’t think so… people who know business need to pick up telephone, manage accounts, have lunch as you said with customer. When you ask maybe simple question: “should order be processed on first day each month or last day”, you get stupid answer back which is no answer: “yes, orders are important to us” (???).

    Real product owner as Scrum defines… I not see it. Special business analyst/requirements engineer, yes, this is possible, but such person more part of scrum team and himself not actual user/stakeholder for business problem.

  24. Very nice post!!!

  25. Funny, and some truth in it. The appreciation of technical people however seems to vary quite a bit between cultures. I grew up and worked first part of my career in Holland, a country I’d argue is ruled by middle managers. I even overheard a manager say one time that everyone who still codes after he/ she is 30 is a loser (I’m really not making this up). I now live in the US, where most coders I know are motivated, on top of their game, and well paid. Depending on your seniority and how much value you bring to the company, techs may very well be higher compensated than managers in the same organization, though there’s certainly a cut-off point where ‘responsibility’ (yeah, to produce reports and blame the minions) pays more.

  26. Hey, nice post. I agree: These are the common problems that a Scrum Master has to fight every day. I’ll keep on fighting, how about you? :)

    btw: you can find a lot of articles of this kind for every other process model or project management method. At least, you only have to decide which model or method you like to work with. Whatever your decision is, the humans around you will permanently exploit it for their own ends as good as they can. So hold the line or run like a chicken ;-D *ggg*

  27. you can take whatever dev.proc. oriented “approaches” out of the last 30years and make a very similar “black hat” blog message. same shit different day ;)

    the lesson is clear:
    every system is as good as blablablabla … finally we always end there … money, team, shedules, quality, customers … blablabla

  28. For point #9, it’s not relevant as SCRUM should not be applied in a fixed price project.

    Besides, I’m not sure where you’re standing while writing this post. There’s a few cases such as you’re in a product development company, you’re in an IT department (which you called it a cost center), you’re in an the software development company, or so on. It depends, and there is pros and cons in applying SCRUM in each case. Are you saying SCRUM will never work in all of these cases?

  29. […] Hier ein interessanter Link der zu weiteren Diskussionen anregen möchte! http://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/ […]

  30. Reason 9….oh my. so very true. :)

  31. […] 这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们带上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。) […]

  32. […] Comment! With such a slightly provocative title I will probably have to start with the disclaimer first: what is written here is my own opinion and not necessarily that of my employer. That is, if I still have one after posting this blog. What's more: I'm a big fan of Scrum and other Agile methods. It pays my bills. Uh wait, let me rephrase that a bit more accurate: I'm totally 100 % convinced that Scrum works for software development. Now with these form … Read More […]

  33. Fully agree with your opinions in this post!

    Normally, the velocity of a scrum team is mainly contributed by 2 or 3 key team members. All the other members just do what they are asked for or even less.

    If a company has no mechanism to make sure these key person are well recognized in the IPM, these persons will low down their productivity like the other team members in the later projects. This will make scrum run in a reverse direction when it is designed for.

  34. Great article !
    Love it !

  35. Really nice post, and I think the biggest problem we have is related to the Product Owner scenario that you’ve mentioned…

  36. I understand, that the situations you describe are frustrating so I can imagine that it must feel good to write this wearing the black hat :-). On the objective side I don’t see why Scrum is part of the problem. In my opinion a very skilled team doing, lets say RUP, will produce way better results than a not so well skilled team doing Scrum. It’s just like the Agile Manifesto says: “People over processes and tools”. Thats why I wouldn’t blame Scrum or a process in general on the reasons 1, 2, 4, 5, 6, 7 and 8. You just still need good people. After that the question is (in my opinion) which process or process framework makes them work most effective. I personally haven’t seen a better process framework than Scrum and I guess you agree here.

    Reason 3: I’m not sure if I understand this point. Is project management supposed to put pressure on underpaid and thus demotivated teams? I’m not sure if that really works. I do believe in the good in man so I doubt it. But I could be wrong on this.

    Reasons 7 and 8 on quality: In my opinion it will hurt the product owner and the team, if they have bad quality. Both, personally and professionally. Thus if people experience that it does not pay off in the long run they probably change their mind. If they don’t experience it in the long run, the quality might be just good enough for this use case (like low risk and seldom used features) and better quality would not pay off. But I might oversimplify the situation in this case.

    Responsability 8: “The project manager (or Scrummaster!) will take the blame for missed schedules.” Well, if the team is not responsible then it’s not a team committment which leads me back to “People over processes and tools”.

    Fixed price fixed features contracts 9: Of course we have to face the situation that it’s not always possible to have an agile customer. But the good thing is, that the reality is agile. Or to say it the words of Heraklit “The only constant is change”. Thus you can expect that the customer will come to you saying “Can we please add feature X without additional cost?” Than you can say “Of course we can, if you can trade that with an other feature with the same amount of story points, that you don’t need.”. That often works because you don’t need to invest in a lot of documentation upfront like in RUP. Plus you can build up trust by showing demos in the reviews and you are able to improve by inspecting and adapting. In the best case the customer gains trust and experiences that it’s the most effective way for his budget to be agile and embrace Scrum. In the worst case you made the best for you out of a complex situation like a fixed price contract. This is what Ken Schwaber calls in Scrum “The art of the possible” in the book “Agile project management with Scrum”.

  37. Despite having the disclaimer read, wearing black hat doesn’t mean criticizing without facts, or even based on what Scrum is not at all.

    If you believe you are (or were) putting your black hat, I am expecting some serious and real critics, not these shallow urban myth. Otherwise, it would be better titled as “9 common misunderstanding about Scrum at work”.

    BTW, I read that some people in China (also one of those ping back above). He does take your post seriously, saying you are really making jokes of Scrum (he seems to have difficulty to believe that there are people on this planet would be 100% convinced that Scrum works for software development. Therefore he thinks you must be joking) and discovered why Scrum will never work.

  38. […] 这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们戴上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。) […]

  39. Most good comedy reveals a true life situation. I’m afraid this post is so funny just because it’s reality for a lot of programmers. I have seen many of the reasons in most companies I’ve been working for. Some even had _all_ them combined!
    As far as I’m concerned, I still have to find that agile company. Sad,but true.

  40. […] 这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们戴上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。) […]

  41. […] Why Scrum will never work « Maurits thinks aloud. Share and Enjoy: […]

  42. Hi Maurits,
    Realy like this article.
    I’ve translated this one into Chinese and posted it in my blog.
    Hope you don’t mind.

    http://daydayup.blog.163.com/blog/static/174063869201162911833184/

  43. Hi Maurits,

    Not known you in person, but from your post .. its speaks what runs in our mind.

    I’m taking up the challenge of soaking in the benefits and methods of selected part of scrum in our existing “traditional” water fall model of development. Therefore, instead of introducing “scrum” as change process and explain the benefits where again it will land in their head as a management “Changes” to squeeze more out of them.

    What you have listed is very true challenges and practical aspects which may become obstacle, but there is a small percentage of chance whereby we can benefit some of the scrum techniques with mix culture of existing process. Do feel free to post your comments about it.

  44. I do know that some outsourcing company enjoys fixed bid projects very much using true Scrum (not the Scrum Buts), and secured many repeated client deals because of that.

  45. QuickLinks for July 2011…

    Here a quick list of articles I´ve read during the last month: Project Manager and Agile? Spotting the Balance A Sample Format for a Spreadsheet-Based Product Backlog How to implement loops in FitNesse test fixtures In The Brain of Gojko Adzic: What is…

  46. Strictly speaking, Scrum is a framework, and not process. Like in every other situation, you need to get the right people on the bus, to make things work. In this case, the “right” people includes the “right” PO who can understand the customers and deliver the message to the developers, the “right” developer who is self-discipline, and the “right” manager who act as a scrum coach/mentor (etc).

    I do agree that the scrum transformation is difficult due to the existing culture and environment. No “right” people would like to get on the sinking ship.

  47. Hmm wordle’d –

    http://www.wordle.net/show/wrdl/3943764/Scrum_Black_Hat

    Can we see the white hat version?

  48. […] by xiaoming at 10:26 am under Tech Recently, a blog post by Maurits called “Why Scrum will never work” broke the quite village of scrum and agile community in China. One of the popular technical blog […]

  49. […] 导语:日前,酷壳站长陈皓编译的一篇《为什么Scrum不行?》再次引发了敏捷社区的一阵骚动。原文出自《Why Scrum will never work》,在那篇文章中,原作者分析了Scrum不适用的几种情况。当然,作者并没有对Scrum全盘否认,而是做了负面思考——思考事物的负面因素。因为这样才能更全面的分析一项事物的优缺点,并知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。 […]

  50. This blog post is both enjoyable and sad at the same time. It is enjoyable because it is a kind of satire of Scrum. However, it makes me sad since it is a very precise description of the reality. It does not really matter whether or not the writer presents Scrum the Scrum in the “right” way. What matters is that the implementations of Scrum are often suffering from the symptoms mentioned here. That might be one reason why “pure” implementations of Scrum so rarely works (and they are also quite rare to find). I think that agile has become a kind of “religion” among software developers and it is refreshing to read so brave criticism about them.

    By the way, are you still working for the same employer?

  51. Hi Maurits,

    I thought that Scrum (well for many) already works… There are some real projects delivered with Scrum…

  52. […] 原文:《Why Scrum will never work》maurits.wordpress.com/2011… […]

  53. […]   这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免责声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对软件开发可行。 […]

  54. Hmmm… This is not intended to be flippant, but I can’t see how any team you are on w/could value you as a contributing member with this particular view of the world.

    “Victim” does not make for a good team member, and certainly does not make for a valued scrum team member who is responsible for making the team better every day. If you are stuck in a state of vilifying others, blaming and distrusting others, then it will be difficult for you to contribute in a meaningful way.

    So, my very genuine question to you (and those who agree with you) is this: If you see these kinds of problems, what are you doing about them?

    If you are choosing not to do anything, then I wonder how you can blame anyone else for these assertions?

    Just my opinion.

    Thanks for sharing your thoughts. Always intriguing to see things through another filter.

  55. This is just another fad.

    I’ve been in the field for 40 years and wish I had a dollar for every new methodology, framework, language, project / team efficiency software, or IT management theory that has come and gone. Every one was bound to increase productivity, empower team members, reach new heights of business value and ROI, and allow essentially mediocre companies leap tall buildings in a single bound.
    In the end, it has always boils down to:

    1. Really good software is produced by really good designers and programmers.

    2. Really good designers and programmers are born that way, not made that way by training, methodologies, frameworks, platforms, languages, etc. etc. It’s in the DNA.

    3. Really good systems are overseen by really good project and business managers.

    4. Really good business and project managers are intuitive, common sense, smart, not necessarily technical, and able to positively influence and guide the self-absorbed idiots at the top of the organization’s food chain into the right direction. They, too, are born – not made. No methodology framework, crapBOK or certification will make any ol’ agile fool into a good IT leader.

    5. Most software projects fail in real terms (altho many are papered over in some fashion) and not because of the methodology, tools or theories employed.

    • I totally agree. I have 25+ years and scrum is nothing but a complete child like process. We are currently rewriting a system that scrum was previously used. They now know what they want to build and decided to take down their scrum boards. One good thing the CEO said about scrum was: Well, at least we got a visual prototype of what we really need build. Only this time we will do it right and hopefully keep the customers that we still have.

  56. […] 这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免责声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对软件开发可行。 […]

  57. Good Environment = Good People = Good Software = Profit

    Bad Environment = Bad People = Bad Software = Loss

    In a Google talk Ken Schwaber said that if you have a bad team you will consistently deliver bad software every 30 days.

    Good People are your most important currency. Individuals and Iteractions over Processes and Tools.

    • With many years of experience working with many types of teams and various methodologies I have to agree that the skilled people on the team matter the most to successful software. The “agile manifesto” types are definitely not that and it is sad that the industry hasn’t grown out of this phase yet. The use of the word “manifesto” tells you something. Flexible, collaborative, emotionally intelligent people are what produces great software. People often have to decide on the fly when things are working or not working and what kind of meetings, design documents, test plans, tests, integration tests, user story/use cases, communication plans etc. will keep the project on track. Agile adds nothing but childish buzz words from the game of rugby (scrum, agile, sprint) and is known to alienate a lot of developers! It is quite clear that agile methodology hasn’t solved the software crisis at all and has definitely created a load of other problems in the industry. The fact that a scrum evangalist writes such a round about message tells you something.

  58. Can I just say what a comfort to uncover someone that actually knows what they’re discussing online. You definitely understand how to bring a problem to light and make it important. More people ought to check this out and understand this side of the story. It’s surprising you aren’t more popular since you most certainly have the gift.

  59. Anyone who says that waterfall fails has no clue of what their talking about. I’ve been in the IT industry for 25 years and have been on 50+ waterfall projects and all have been successful except two, which had nothing to do with the process but company direction.

    In the last 2.5 years, I’ve been involved in scrum and it’s like being in kindergarten. As an architect, agility comes with fragility. The architecture in some scrum related projects are so bad that separations of concerns are all over the place. I’ve been hired to fix their issues of bad designs due to lack of requirements, and let me tell you it smells very bad. Their unit testing sucks, no isolation as most their unit tests are more like functional tests. I told the CEO that software is like building a house. If you forget the basement and decide its best to put it in later, guess what? You’re better off rebuilding the house as it will cost you a lot less in the long run.

    Let me tell you something: Not knowing what you want to build upfront is complete nonsense. Can you imagine building a NASA Shuttle or a 747 using agile/scrum? I don’t know about you but I won’t fly either.

    Software like any engineering project requires a foundation that is modeled first in blueprint (UML) then later developed in to a pilot. Waterfall is based on design upfront from well-defined requirements/specifications with use cases, and then later developed/QA’d with 4-6 week milestones (sprints). Requirements that come up later are reiterated where necessary. Usually they are small and normally don’t affect the main foundation. It works well and will always work well. Hence, why mission critical applications will never be built using the scrum process. Scrum is great for prototyping something quick and dirty. Prototypes are then thrown away and should never be used as the foundation moving forward. Pilots on the other-hand are different. Scrum is also good to maintain and enhance systems with very light requirements. But as soon as requirements have a major impact on architecture, watch-out!

  60. If I was working with you, you would be my best friend at work. I am just quitting my 1 month old job today because of this bullshit called Scrum. Scrum is built for consulting companies, so they can spend more time on bullshit, and charge the customer more. A good developer would never deal with this drama.

  61. […] 这篇文章的原文在这里(原文链接)(下文不是全译,也不是部分译,我只是把其总结,有我自己的发挥,但是原意大致不变),这篇文章完全是在调侃Scrum的,作者第一段就是一个免费声明,其说他是Scrum和其它敏捷方法的big fan, 他也认为Scrum 100% 对 软件开发可行。作者使用Scrum 5年了,也公开作过几次敏捷的分享会。他觉得写这篇文章只是为了好玩,因为他们戴上Edward de Bono 的 black hat (黑礼帽 – 是6个思考之帽中的一种——负面思考,思考事物的负面因素,这样才知道:它会起作用吗?缺点是什么?它有什么问题?为什么不能做。) […]

  62. Perfect ! Good Peoples resolve problems, no Scrum Miracle

    • Yah. F*ck those processes. We dont need all of em.

      • Very good, just one line to explain it. Like it. It seems to be more about processes and modelling rather than writing good and efficient software.
        Have done a test lately at a company because searching for a job. Technically it was good/fine/excellent but had no SCRUM experience. Didn’t get the job because of that, knowing SCRUM is most important. Where is it all about? Don’t get it, very frustrating.

        Not knowing this bullshit and you are completely worthless even when you are good at programming. I think SCRUM is a marketing thing, used to make people/clients believe that long development roads are good and to incorporate clients that do not really know what they want. Result: Money but it is not sure the client will be a happy with the result and it seems that is not important because is it not about quality of the software. Main goal is to produce as fast as possible even when it is worthless, to be able to show something. Fast results != good software.

        Besides, SCRUM is OLD, also MVC (also a crappy method and doesn’t work for large projects because it can complicate things) is OLD. Old doesn’t mean it is not good but it is like with technology, some day you find edges. Some business man thinks to bring some old as something brand new. A new hype is born. Look at the cloud-hype for example, it was there but in some other form. It is just to bring something new.

        I really hate this situation in I(C)T these days because it is NOT about writing good, efficient and fast software but about processes and modelling. Hate it.

    • My comment below was meant for @Leonardo – “Perfect ! Good Peoples resolve problems, no Scrum Miracle”. I cannot change post below for ome reason..


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com. | The Pool Theme.
Entries and comments feeds.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: