I recently wrote about some reasons that standardizing your development process is a terrible idea. But I’ll admit there are a few reasons that it might be a great idea instead.
Depending on the company you work for, you might need to comply with certain external regulations. At a minimum, you’re going to have to write down what your process is and adhere to that process, which will require some level of standardization. This doesn’t mean you need to document and control every part of your development process; less is probably better in these cases.
I’m sure we’ve all seen the teams where the “Scrum Master” dishes out assignments and treats the daily standups like a status meeting. Whatever that is, it ain’t agile. But as long as they’re using the right words, and in the absence of any standard, what’s to stop them? A standardized process is objective and can be assessed. Standardization will force an organization to actually flesh out what kind of environment and processes the people will use. With some level of standardization, at least there are some rules that teams can go back to when faced with various situations – the temptation to blow off unit tests, pressure to work at an unsustainable pace, etc.
Along these lines, a standardized process can help keep a team from slouching toward mediocrity. It’s nice to think that all developers are highly disciplined and will stick to the best practices they have mastered. But it doesn’t tend to work out that way, and before too long you’ve blown off pair programming, the daily standup takes half an hour, the end of the iteration slips now and then, and nothing is ever “done done”. Woops. A standardized process shows us what the standard actually is, and can be enforced when needed to keep us from mediocrity.
A standardized process also allows certain organizational efficiencies that would be hard to achieve with multiple, constantly varying, processes. For instance, if managers can count on getting the same metrics from each team, each iteration, it will help them be able to recognize problems and respond appropriately. When the system adminstrators know just what to expect from the development teams, and when, it will help deployments go more smoothly. If IPMs, retros, and demos, can be coordinated, it can help stakeholders get to those meetings and avoid scheduling conflicts.
Ultimately, though, the best reason to standardize your process – and the reason most people want to do it anyway – is that it allows the organization to grow and learn. Each team doesn’t have to re-learn each lesson. Newbies can come up to speed on the practices before they’ve really mastered the philosophy. Understanding is important, but it’s not everything. It’s OK to learn by seeing what was successful for others. The danger here, of course, is that the growth and learning never come, and good practices simply become tradition with no underlying comprehension of the motivations or forces involved.
In conclusion, I think some minimal standardization is probably a net good, although I’m not sure it needs to be formalized. Certainly you want a default process for teams to start out with. Any level of standardization must leave room for experimentation and innovation within that process, and can never be a substitute for learning and understanding.