My nephew, who works for a medical device manufacturer, is getting into project management. One of his gifts last Christmas was a hefty volume on Six Sigma, given to him by a relative who has used the same book for years during his own long career in project management for a large IT services company. Since I've written about Six Sigma, I began talking to the two of them about it over dessert following the holiday meal. The Six Sigma veteran told me he didn't always follow the methodology to the letter. Sometimes he applied just the aspects that he felt were needed to achieve a desired result.
I could see how this would be problematic with any framework that stresses standardized processes. What's the point of using a methodology if you aren't going to adhere to it? At the same time, I've encountered folks using Six Sigma and other methodologies for whom the means have become more important than the end. They appreciate process for process' sake, not for the results that well-executed processes should yield.
Agile software development was supposed to be the cure for the rigid processes that characterized traditional waterfall development. Yet agile developers can still get caught up in process for process' sake, writes Wille Faler on the Agile Zone.
The cultural mindset and discipline of development teams, not the development methods used, are what's important in producing quality software, Faler says. If developers are too process-oriented, "they will jump through the set out hoops, expecting results to magically appear at the end of the rainbow, even if they never understood what the desired outcome was in the first place."
Good developers understand the importance of outcome. Here at IT Business Edge, our development team uses a hybrid approach that combines elements of agile and more traditional waterfall development, our VP of software development told me. Similarly, Mozilla's director of Firefox has said it is "not tied to any specific development model. We're tied to what is effective."
Falle offers a five-step plan for producing quality software, which should work well no matter which development method is used. His first two steps-understand your business context and determine a clear desired outcome-suggest developers need to communicate closely with business users, something our VP mentioned to me repeatedly when I spoke to him about ITBE's development method. Everything else should follow from those steps, writes Falle. For instance, he advises dropping any requirements not needed to achieve the outcome. He writes:
Do you need a given requirement to minimally fulfill your overarching goal? Really? Get rid off, cut out and strip down requirements aggressively, get down to the bare essentials. If your big goal is too big, cut it down. If you want to make it nicer, do it later.