Soon after an organization adopts agile software development methods, it seems that mangers inevitably talk about the need to “mature” and “standardize” their process. Here are a few reasons standardizing your agile process is a terrible idea.
Standardizing on a process, across teams and projects, prevents innovation and progress. As the Agile Manifesto urges, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” If a process is standardized, then it will be either impossible or very difficult to adjust your practices. One thing I really love about iterative development is that you can run experiments on your development process itself. You can modify your process for an iteration or two and see how it works. If it’s an improvement, you can continue. If it’s detrimental, then at least you learned something. Rigid standardization prevents this.
In the worst scenario, standardization can force teams to knowingly do the wrong things. No project is alike, no team is alike. The context always varies, even perhaps from iteration to iteration. The fact is that a “best practice” for one team may not be a good practice for a team in a different context. There are few, if any, absolutely best practices that are applicable to all situations. A standard process can force a team to follow a rule that it intuitively knows to be inappropriate.
Standardization will require some type of process or oversight, which will exist solely to enforce the standardized process. There will be some amount of work involved to make sure each team is following the rules. Otherwise how do you know that team down the hall is actually doing TDD instead of just writing tests after the fact? Somebody has to own, and enforce, the process. This flies in the face of simplicity – maximizing the amount of work not done.
A standardized process ruins the outcome-oriented spirit of agile software development. If a rigid process that I can’t change is being enforced, and I follow the process and work diligently, I can’t be held accountable for failure. After all, I followed the rules. Instead, development teams should stick to the motto “Get ‘r done!”
Related to that, standardizing a process removes need to actually understand why certain practices exist. When you don’t have to derive, or at least continually justify, your practices from first principles, then it’s fairly easy to not bother understanding what those first principles are, and how they correlate to your practices. Allowing teams to vary their process as needed will help ensure that those processes flow from actual common values.
I’m not against all forms of standardization, and I think an organization – even the entire craft of software development – should have some “default” practices. Stay tuned for a future post on why standardizing your process is a wonderful idea!