Post date: Feb 13, 2012 5:13:17 PM
There is no "true" chili. Those of us who love this spicy concoction understand this. For every region, there are different flavors. For every recipe you know, there will be a dozen others you don't. And almost all of them taste good, in the right place and at the right time. You can find some basic commonalities - a chili often has onions and some sort of pepper, for instance; but for every "rule", there seems to be a recipe that shows that the exception can be just as tasty. Chili aficionados have responded to this uncertainty by generating a plethora of variations. And, even if you hand a chili cook a recipe, he or she will usually modify it somehow.
It's the same with software development processes. We are handed cookbooks full of procedures and rules. Sometimes these fit. Sometimes they don't. The reasons why things might not fit come from many different directions - the nature of the market and its timing; the nature of the organization; the nature of the product, its delivery mechanism, and the tools used to construct it; the nature of the team - all of these can impact whether or not a particular part of a process is effective. More importantly, sometimes these forces can make a portion of a process worse than ineffective - it might take more work than it saves, creating more work for your team without providing additional benefit. As such, it's clear that processes often need to be modified.
In addition to removing inefficient practices, processes can be improved by adding or replacing procedures. I've seen traditional processes improved by importing steps from the agile world - using TDD practices or delivering frequent intermediate builds can often help a traditional team achieve better quality. Depending on the product and frequency of market or requirement changes, an agile methodology can be improved by formalizing and adding a bit more structure. The main issue is to always be aware of what's working and what's not working and fixing the thing's that aren't.
Occasionally, you'll want to change processes anyhow, just to boost your team's efficiency via the Hawthorne Effect. Plus, introducing teams to new process practices will help keep them fresh and ready for change if (actually when) your team's environment changes and you need to change your processes in response.
So, if you're the leader of a team, don't be afraid to change your processes to make them more effective - make them your own. Keep trying to make your team's development and project management processes more effective. It may take some experimentation to come up with the right mix of process "ingredients", but the payoff will be in the tasting - when your high-quality product arrives on time.