Re: Nobody Expects the Agile Imposition (Part V): Meetings

[sundialsvc4]

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.

[ruoso]

While I mostly agree with you, there is one important aspect of what Scrum is:

Most of the scrum BS is targetted at the developers morale, I mean, it looks like theater because it is meant to be. The idea is that the young developers, eager to be part of a cool project, take part of entertaining project events, such as the poker play or other theatrical parts of the scrum methodology.

Of course more experienced developers know this is bullshit and they usually want to skip it, the ScrumMaster (a good one) should know this is bullshit but he should also know that the bullshit is important to keep the developers motivated -- often it is also helpful to look cool for a customer that is a tech wannabe, so he also needs the "cool" stuff.

In terms of methodologies, there is, in fact, one aspect of the agile methodologies (be it scrum, xp or whatever) that should be taken into account. They share the idea that the risk of the project as a whole (in the sense of the actual value added to the customer) is shared between the devel team and the customer. That meaning, if some prioritization is done wrong and the software misses one important feature, it's not the "requirements analisys" fault, but "bad judgment by the customer" -- even if it is something the customer is not experienced enough to know but the devel team is supposed to know.

The good part is that it cuts down most of the coordination cost, the bad part is that if the customer is not fully aware of the risks he is taking, it could lead to very dangerous places.