Putting the facts up front, we, at DCG, are SEI Partners and advocates for CMMI.Â Perhaps that is one of the reasons that our ears are finely tuned for criticisms of CMMI.Â Many criticisms are baseless and a consequence of misunderstanding - wilful or otherwise.Â Some are real and have a firm basis in experience on the ground. One such criticism is CMMI compliance does not necessarily equate with good software in all cases.Â This is the consultants way of saying, "They may be CMMI Level x but their code is awful."Â Is it fair to suggest that, sometimes, efficiency does not necessarily lead to effectiveness?Â "All the indicators are green but there's something wrong."Â I have heard clients complain about software produced which is, "compliant with requirements but never innovative". Here at DCG, we seek to mitigate such issues by deploying a portfolio of software development best practices through a Value Visualization Framework.Â However, I saw an interesting article by Joseph M. Hall and M. Eric Johnson in the March 2009 issue of the Harvard Business Review. In their article, "When should a Process be Art not Science?"Â Hall and Johnson argue that the movement to standardize processes has gone overboard and that some processes require an artists judgement and should be managed accordingly.Â They mention software development as an area in which this can be true and. although they don't mention it, their argument resonates very strongly with the Agile Manifesto (make this link). So how do we manage art? Hall and Johnson propose a three step process: 1. Identify what should and shouldn't be art 2. Develop an infrastructure to support art 3. Periodically reevaluate the division between art and science Again this resonates with our consulting experience in agile development shops.Â Too often, the success of agile implementations is constrained to only one or two successful teams because only step 2 is implemented.