Glen Alleman points out a problem he sees the current agile project management community not giving enough attention:

So if the group is accountable how does the group come to a place where decisions stick? This is one of those differences between principle and practice that is missing from the Agile PM discussion to date.

That last sentence is basically a bait for the rest of us agilists to spend some cycles on thinking about the problem. I took the bait.

Now what are the factors that contribute to making a decision stick?

First of all, it is essential for all involved to know the rules--who gets to "vote" and with "how many" votes, who has the power to make a final call, and the decision making process in general. Having a team member left unsure about what his role is in making the decision is the worst thing that could happen from the perspective of having that team member put effort into the decision and therefore committing himself to sticking with that decision.

Another practical technique for improving the decision's chances of sticking is to have all team members first formulate their own position on the subject independently and come up with some arguments for that particular position. Creating this "think time" for everyone is likely to decrease the risk of the loudest voice walking over the others. Similarly, it often helps if the decision is spell out by someone else than the one who suggested the selected alternative (and there should always be alternatives!).

One final aspect that's important to pay attention to--before making the decision--is to discuss the outcome. Yes, we all think of the outcome when evaluating our options but it makes sense to spell these out explicitly. There's a good chance that I've missed an aspect of a particular option's expected outcome and the more useful information I have on my options, the better able I am to make a decision I can commit to.

Also, we must remember that sometimes it makes sense to turn on an earlier decision. The extremes are rarely optimal and that holds also for decision making frequency; intense trashing isn't much better than having an annual decision making day...

Cedric voices his concerns of someone on the TDD mailing list "requiring a shrubbery before using the debugger".

I won't comment on the actual topic beyond stating that, yes, it doesn't make sense to ban the debugger completely but if there's an economical way to avoid a debugging session, of course we should go for that.

Now, the real reason for this blog entry is that Cedric mentioned shrubberies. For all you Monty Python fans out there, have a few minutes of fun with these.