This is what software development is all about. So simple in concept, yet seemingly so hard to accomplish. A development organization that can’t deliver what’s needed is a wasteful expense, not to mention a generator of false hope for those who were expecting some output. So how do we know if any given organization actually has the ability to deliver?
There is really only one answer, which is the most obvious one: Has it been able to do it consistently in the past? If “yes,” that’s all the evidence we need. (“Yes” means that whatever was delivered met or exceeded expectations for functionality, quality, and timeliness by both customers and the company). Whatever is being done works, and for an organization with a bad track record or no record at all, there’s just no way to know for sure.
So if a track record is all that’s needed to gauge an organization’s ability to deliver, why are there other methods such as CMMI that attempt to measure development organizations? Probably they spring from the irresistible urge to measure and classify things, especially for those who subscribe to the idea of “You can’t manage what you can’t measure.” (I will address this topic in a future post.) Presumably if the assessment method measures the right things, it will help a development organization to do better. So let’s assume that there actually is value in using some assessment method.
There are several assessment methods to choose from. At one time or another, my organizations have been through formal assessments for ISO 900X, Malcolm Baldrige and SAS70, as well as CMMI. In my opinion, they’re all pretty much the same: auditors come in and look for “evidence” that your organization has documented its procedures, that people know how to use them, that you have written evidence of their use, and that you are measuring the results. The underlying motivation for all of these is sound, but I find all of these methods deficient because they don’t measure an organization’s ability to deliver, which includes satisfying its customers (Malcolm Baldrige might be a partial exception to this).
So if I were called in to assess a software development organization, after looking at its track record (which would include getting a gauge on customer satisfaction), I’d be inclined to use the Agile Manifesto as my yardstick. In fact, the 12 principles behind the Agile Manifesto might make a great set of competencies for the “Performance Document” of a development organization (just like many cmpanies do for appraising employee performance, although see my note below). While following them does not guarantee success, I think they come much closer to providing guidance that will result in improving an organization’s ability to deliver than any of the other methods.
Important note: While I have suggested using the 12 principles as a yardstick, it would only be for informal use and not to produce some type of formal assessment score (if that were even possible). They should be used only as an improvement tool, not a measurement and scoring tool. Following a process is not the goal of development – it is only a means of achieving the goal, which is to deliver the product.
If you haven’t looked at the Agile Manifesto and the 12 principles behind it, it’s really worth doing. Do your own quick mental appraisal of how well you and your organization are following each one, and then think of what you could change to follow them better. And while following a few of the principles is better than following none of them, I think to be fully effective an organization needs to follow all of them.
Earlier I raised the question of why any kind of assessment might be needed for a development organization other than just a track record, so I will now propose an answer, specifically with the Agile Manifesto in mind:
- For an organization that is not satisfied with its track record, following the principles behind the Manifesto and executing them well is probably the single best thing that could be done to help it establish a good record.
- And for an organization that already has a good track record, following the principles will help it improve the effectiveness and efficiency of its ability to deliver, because there is always room for improvement.
In either case, I believe that following the Agile principles will do a better job of helping an organization improve than any of the other formalized assessment methods mentioned earlier.
In the end, it’s only the ability to deliver that really matters for a development organization.
