One of the most dazzling changes to the software development world in the past decade has been the spread of agile methods; initially Extreme Programming (XP), and now mostly Scrum, which has tended to subsume all others, since many projects that apply Scrum also use, knowingly or not, elements from XP, Lean Software and Crystal.
I became fascinated some years ago with agile development, for three complementary reasons: the powerful insights it provides; the bizarre and sometimes outright catastrophic advice with which they coexist; and that very coexistence. Such a phenomenon is rare: usually our personal "Identification Friend or Foe" device functions well, and we can quickly embrace a new idea as productive or dismiss it as silly. With agile methods, the worst jostles with the best, sometimes, in an agile book, from one paragraph to the next.
At issue is not just the innovator's natural proneness to promote his ideas with, at times, a bit too much enthusiasm. We saw that with earlier software advances such as structured programming, object-oriented programming (in whose promotion I played my part) and design patterns. You might get carried away here and there, but you stick to rational discourse; you do not ask the reader to genuflect and start praying.
Over the past years I decided to play the game and sing the song, became a Certified Scrum Master, read all the agile books I could find, applied some agile methods in my own projects. The more I went the more I became incredulous: how can such brilliant ideas as the "closed-window rule" (during an iteration, no one regardless of rank and station can add functionality, other than by canceling the iteration) appear in the same texts that tell you to forsake upfront requirements and design, and pretend against all evidence that you can build a system by piling feature upon feature (or worse, "user story" upon user story)?
My just published book [1] is an attempt to sort out the jewels from the gravel. There is so much to be learned from the best agile techniques that it would be a pity to throw them away altogether because of their catastrophic elements. I do not expect everyone to agree with every single one of my assessments, but I hope this attempt at presentation and reasoned analysis will help the software industry benefit from what agile methods genuinely can bring to us.
[1] Bertrand Meyer: Agile! The Good, the Hype and the Ugly, Springer, 2014. Book page here, Amazon page here.
I just finished reading your book, which was not only informative but very fun to read!
On the Hype side, you might appreciate this Ted Talk, extolling the virtues of applying Agile methods to organize your family life:
http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family
Displaying 1 comment