in reply to Nobody Expects the Agile Imposition (Part V): Meetings

Fifteen years ago, the “magic bullet” was, well, something else.   Twenty-five years ago, something different.   Thirty-five years ago, someone wrote The Mythical Man-Month.   (It was a great deal easier to read than Programmer’s Death March, or maybe that’s just me...)

I am pleased to see, however, that the wheels of commerce are still turning:   whether or not software development actually bears any resemblance at all to the game of rugby, you can still make money selling the idea to fat, overweight managers whose only actual tangential involvement with the game of rugby consists of ESPN and beer...   and getting them to pay for “certifications” from you on their way to ensuring continuous employee turnover.

Pardon me for being cynical.   Naw, strike that.   Maybe I’m old enough by now to say that I don’t particularly care if you find my words to be cynical or not.   There is no silver bullet.   “Silver bullets” always devolve into pathetic rituals that only make matters worse, as people obligingly pay lip-service to them but no more than that.   (Go ahead... fire them if you want to.)

Software development is no more strange an undertaking, and no more intrinsically complicated, than “building a house, starting with a blueprint the creation of an original blueprint.”   Which is, by the way, an immensely more complicated task than it may initially appear to be.   And, “aye, there’s the rub scrum.”   Making people’s live miserable and demanding that they hand over their days, nights, weekends and (!)-life if they still have one to you, won’t make your software any better:   it will just make it take longer as the really good people that you want most won’t put up with that (!) will leave.

Pretend that the thing that you are building is not intangible.   Give up on the notion that it plays by different rules from anything that has ever gone before.

Emphatically, what fails the most in a software project is internal communication.   Things get dropped and overlooked because there is no mechanism in place for keeping track of them.   Software goes into production un-tested because there is no actual mechanism in place to test it, and no time in the schedule to deal with it when problems surface.   Silver-bullet “solutions,” and the expectations that go with them, merely exacerbate this problem.