Buzz Andersen collected a couple explanations for why formalizing a development practice into software can harm a team.

In the context of startups, project management tools will always suck. If you are using a PM tool then you are not designing, coding, or communicating with customers. You are not even communicating with your team. ...

Getting e-mails that say “UserName has assigned you task: XXXXXX” sucks. Developers and designers aren’t fucking robots.

Last time project management came up in a conversation, I suggested that the point of a retrospective is to maintain the team's charter. Maybe I had Independence Day on my mind, but I liked the idea of that charter being the literal constitution of a project. (After all, it's that which constitutes.) A new team is chartered not only to build a particular product, but to pick how they're going to do that, with practices like “we work to a weekly rhythm” and “we depend on automated tests and have Jenkins run them for us.” Even for a simpatico team that leaves these rules unwritten, they exist, even if they're the software process analogues of the null hypothesis.

The retrospective, then, is the constitutional convention where the team can review its charter to agree what still matters and fix what's broken. While those teams that are synchronized enough can intuitively change the team's heart as one, the last thing you can afford is to think you're one merry band until a surprise schism has you relitigate the basis of the project. A regular time and place to discuss changes also seemed to help the last team I was on work together as a large, diverse team on one project.

I happened to pick through The Best Software Writing I again yesterday and found Clay Shirky put it the same way, referring to “constitutional crises” like the rescission of LambdaMOO's “new direction.”

And the worst crisis is the first crisis, because it's not just “We need to have some rules.” It's also “We need to have some rules for making some rules.” And this is what we see over and over again in large and long-lived social software systems. Constitutions are a necessary component of large, long-lived, heterogenous groups.

Whether your team is big enough or diverse enough to need to vocalize a charter is up to you to discover.

Maybe it's my inexperience but of the particular practices Andersen mentions, I still find the idea of points helpful. From the nature of what we do, I don't think I'll ever be able to accurately and repeatedly predict how long it will take to do some future work—so when I need to be able to predict, it makes as much sense as anything else to use a running average of past performance. (If the terminology is the problem, yeah, I hate that these things use their own weird vocabulary, but in the case of points I'll take it over “hours per hour.”)

I think this idea of a team governing itself is the spirit behind a lot of the practices decried in the articles. (I know apologists for these practices always say this.) Too many of the methodological tools end up about the practice instead of the work—necessarily, as it's practice that can be captured in software, never the creative work that the software assists. That's not bad, that's just how tools work. Instead, the more that agile practice is about the self-governance of a team, the more I agree with it. Tools come and go, but ultimately the tree of creative liberty must be refreshed from time to time with the sweat of project patriots.