Editorial Note: I originally wrote this post for the Telerik blog. You can check out the original here, at their site. While you’re there, have a look around at their extensive product offering.
In a whitepaper I wrote recently, I talked about two hypothetical organizations. I used them to offer a study in hyperbolic contrast.
The first had a team of five developers, none of whom used the same development practices. In fact, one of them used a completely different programming language. They tracked defects using email, and they operated less as a group and more as a collection of ships passing in the night. If a customer issue arose in the code of a person on vacation, well, then that customer just had to wait.
On the other side of the aisle sat a massive enterprise. Here, the team not only used the same programming language, but the same everything. The organization restricted access to the machines so that developers couldn’t install anything of their choosing. Instead of leaving things to chance, an architectural center of excellence controlled design decisions. And any deviation from any practice required forms in triplicate.
I used this hyperbole to draw contrast between teams that could benefit from standardization and teams crippled by it. Predictably, scale plays an important role in the distinction. To scale an enterprise, one must standardize some operational concerns. But in doing so, it risks choking the life out of individual innovation.
How can you standardize while minimizing bureaucracy? Today, I’d like to offer some tips for striking the balance.