Wednesday, March 12, 2008
Are Software Engineering Process Groups (SEPG) an antipattern?
While it is true that the few truly successful SEPGs achieved high levels of maturity by having specialized skills and knowledge outside of traditional software engineering, they also had folks that understand
One interesting observation is that software development teams tend to fail to deliver because of suboptimal communication. So of course the solution to this problem is to further confuse them with poorly contrived concepts that came from Carnegie Mellon. We should also embrace CMM which was supposedly a way of evaluating the quality of a software team and twist it into other usages. If we create comprehensive documentation filled with lots of formal rigorous stuff that nobody understands this should most certainly help with our communications problem.
If developers are always late at delivering software then we can most certainly help increase their productivity by having them fill out arduous status reports and the TPS cover sheets more frequently. By adding to the bureaucratic thinking of the enterprise, productivity will almost always increase only not for the folks who actually write software.
We all have learned that agile, iterative ways of developing software are much better yet the SEPG folks and their heavyweight processes almost always pushes one to conclude that maturity is achieved by big design upfront and other waterfall like approaches. Maybe I shouldn't complain so much in that CMM has created a lot of US-based jobs. If CMM were easy to understand, there would not be an industry filled with insultants to support it.
Sage wisdom also tells us that you cannot manage what you cannot measure and CMM stresses the use of metrics. Of course, it doesn't tell you what metrics to capture only that you should capture them. Bureaucratic folks will tend to gravitate towards collecting metrics that are easy to capture but otherwise don't measure value. I bet your own SEPG isn't capturing useful metrics such as number of bugs per release. After all, isn't the goal to understand whether software is getting better or not?
One common problem in many enterprises is that folks have no clue how to develop, test and release software into production anymore. They're too busy making their feathered cloaks and crocodile-head hats to wear to process governance meetings that eat up way too much time. It has once been said that like enterprisey architecture, the emperor has no clothes...
Links to this post: