Why Agile sucks and you should hate it


Published on

Slides (without notes) from my talk about agile methodologies. Despite title it was pro-agile talk. Slides and talk were done with little preporation.

Published in: Technology, Spiritual
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Greeting What is agile?
  • It just a word. It came from manifesto How it was...
  • KB organized XP conf in 2000 Among invitees was Robert Martin
  • Uncle Bob liked the idea and decided organize something similar with guys from other methodologies Feb 2001 with 17 out of ~20 invitees
  • They didn't plan to write a manifesto nor did they use “agile” word (“lightweight”). Came up with manifesto Ward Cunnigham (wiki creator) published it on ___ website. So what? Who knows about “software craftsmanship” manifesto? How did it get popular (OOPSLA 2001? MF?). Why?
  • Bred: conspiracy theories, civil war in Salvador.. and “follow the money” Who signed manifest. (it would make sense for them to do it to create synergy and make profit)
  • Great for consulters (e.g. P-programming is good to sell), trainers Agile Russia, Denis Miller “How to sell agile”, “I'd sell shoes”.
  • Dmitry Lobasev “retelling” books What is narrative fallacy Uncle Bob on unit testing videos in inet RoR guys from community meeting
  • Confirmation bias in unit testing. You seek for confirmation of something you want to believe in. The way one “get hooked” on a technique. No empiricism, not “agile”.
  • Believing is part of religion. xrcat story about XP being a sect by checklist.
  • Don't agree with agile approach – you know nothing about methodologies Don't use agile – you are dinosaurs It doesn't work for you – you don't use it properly and...
  • ...don't even mention waterfall. I have never seen waterfall in practice. All the companies use ad-hoc (code-and-fix; classical) approach. Even if process is claimed to be waterfallish, in practice it's masked ad-hoc. Why always mention waterfall? My guess someone wrote about it, then it's narration fallacy (you need enemy).
  • Agile is cool! Not Agile – looser Labeling yourself as agile just for the sake of name “ everyone” gets agile IS story about RoR guys not telling they don't write tests; ror meeting story. (ror is agile web framework) Nihilism and “showing light” themes in books about agile (well... it's probably common theme for writers). Sometimes programmers-centric; it's great to feel unique and important)
  • Agile is often mentioned without any context It's iterative, but do we really need it all the time? Do we really know so little about what we do?
  • FDD creates overhead, it's more expensive One could call it “waste” (TPS, Lean)?
  • Clients are the reason we do what we do. Never heard of anyone asking for agile, only about problems with convincing clients
  • (saying about documentation is weird in DB) Cemal story about critical server Documentation is good User stories are not enough Acceptance testing. Is it going to answer “why” and create big picture?
  • Professionalism => specialization It's claimed that agile makes programming more professional (Uncle Bob, Scott Bain) Cross-functional agile teams?
  • Almost 9 years since 11-13 Feb 2001 Have it moved industry? Hardly. At least most of people heard about it. Probably it made a lot of people think about methodologies. I know only one Russian company really using agile. Technological impact (which is more understandable for me)
  • There is unit testing framework for every language, there is unit testing tool for every major IDE But who uses it? From I observed by asking people on conferences it's almost no one “ unit” is overloaded term; it it's original meaning it's used by even less than almost no one Using xUnit framework doesn't mean you write unit tests Quoting Jay Fields “Unit testing is in beta (~10y since junit) But it does work
  • Refactoring is also in every major IDE (for mainstream languages or to some extent) Developers have always been kind of doing it (but naming it as a separate activity is good) Related to R is tech debt which is also a great notion; but who knows about it? Among those who can measure it? Or use it properly (like taking when needed and then paying back)? (Like in finance debt is not necessarily a bad thing). MF: “Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code.” => see previous slide. (telamon (JUG) talking about refactoring but not writing tests). Who does structured refactoring as in the book step by step? Haven't seen anyone in person. We're not doing “ safe ” refactoring with checklists. We are doing “ different ” kind of refactoring.
  • Guess who? OOPSLA2007 – painel “No Silver Bullet Reloaded” (20th anniversary of Fred Brooks's "No Silver Bullet") Werewolf alive => no silver bullets
  • MF normal look InfoQ: People ask the question, "How can we decide a project is Agile or not?" And I think that it's an invalid question, we only need to know how to make improvements ... MF: Yes! InfoQ: ... not to check if it's agile or not. MF: Absolutely. People driving agile are very reasonable . (Quote Merkulov saying: “yes, they are selling agile but it's a great good”?)
  • Oversold by those who just want to make money. Misused by those who are sold agile as a silver bullet and use it without thinking (without context) Unwanted (as any improvement) by: - those who don't want to take risks by improving process (it may be reasonable or not) - those who don't care what they do (I'd rather do nothing than get more money/better position/whatever) (in general it's fear of change ) And... (ignorance)
  • Ask who knows/remembers what is said in the manifesto (last time no one named a single point) I didn't know myself for quite a while (even being fan of XP) (don't say what is in manifesto) It says reasonable things most people would agree with. Agile is general term (and kind of for PMs). XP is somewhat more concrete on what to do (practices), less vague. Most “technical” agile.
  • Who knows what is XP? (common response “I don't like p-progr”, “unit testing doesn't work” (!?)) JUG story about “everyone uses XP” 5 values, 15 principles, 13 practices (base ones); from 2nd edition
  • Most criticized practices (Mind silver bullets)
  • What is your experience? My experience with p-programming - best programming experience ever in KG - worst try with IS (you cannot do it 8 hours a day; even KB says it in XPlained) Bottom line: - it's great for mentoring, introducing to project - in other cases try and reflect (it has value anyway) (optional) How many times you have tried it? how many time have spent p-programming? What if you put the same effort into learning a progr language? (surprisingly last time everyone was very much for p-programming and told about success stories; why don't we use it in day-to-day work? :( )
  • (not a problem in DB) Story about maxoid and xrcat working on same project with different code styles (including tabs) If you want to understand other's code and don't to see crappy code, you should share it. (Related to p-programming)
  • Automated means unit (in “original meaning), acceptance/functional (don't think these are the only kind of test there are... TODO: list them?) How many books on unit testing have read? (I read ~>3 and they changed my views on it) In one word automated tests do work But writing them may be tough. Don't fall into confirmation bias. Don't write tests for their sake (unless you want to explore testability of what you do). They work just great in case of primitive inputs/outputs. But they can be usable in other cases too. Think about what you do, if it pays off. Treat them as beta software. (optional) How many times you have tried it? how many time have spent p-programming? What if you put the same effort into learning a progr language?
  • IMO least known practice from XP My interpretation: Explain what you system does in one, three sentences. Explain to 9 years old child. It's great for everyone's understanding (including yourself).
  • Things we use to some extent... and they are XP practices. XP is not that “extreme” (may be not best name).
  • Remember there are no silver bullets Think before/when/after using something
  • Ask it
  • Disclaimer (TODO: rework presentation, remove disclaimer?)
  • Don't fall into trap of “why” questions
  • Why Agile sucks and you should hate it

    1. 1. Why Agile s**ks and you should hate it [email_address]
    2. 2. What is “agile”?
    3. 5. What is “agile”?
    4. 6. “ Follow the money” =>
    5. 7. “ Agile” is for sale
    6. 8. Narrative fallacy
    7. 9. Confirmation bias
    8. 10. Agile is “religion”
    9. 11. Agile community is aggressive
    10. 12. Agile Waterfall VS
    11. 13. Psychology of agile
    12. 14. Agile “fits all”
    13. 15. FDD can be wasteful
    14. 16. Do clients ask for agile?
    15. 17. “ Agile” documentation
    16. 18. Professionalism and Agile
    17. 19. 9 years in industry Did agile make any difference? almost
    18. 20. Unit testing beta
    19. 21. Refactoring
    20. 24. Agile is oversold misused unwanted
    21. 25. What is said in agile manifesto?
    22. 26. XP?
    23. 27. No silver bullets!
    24. 28. pair-programming
    25. 29. code ownership
    26. 30. automated testing
    27. 31. metaphor
    28. 32. refactoring continuous integration
    29. 33. No silver bullets!
    30. 34. Why Agile s**ks and you should hate it ?
    31. 35. Q & A
    32. 37. Why Agile s**ks? It doesn't! Why hate it? Don't hate :)
    33. 38. Thanks!