Geeks With Blogs
Jeff Smith Software - The Science, The Art, The Teams

I am thinking about those rabid agile guys this morning... what would they think?

Before I go on, I feel I must lay my position out there... Agile methods come from process thinking as much as solid development minds. I have plenty of local agile guys go nuts when I say XP and Scrum are great process, but process nonetheless. But I have a background in process beyond most... and when I speak of process, I do not just think about RUP or CMMI or Waterfall - those are software process models. I also think of supply chains, operations research, the theory of constraints, lean methods (as in just-in-time or the Toyota Production System)... and I think of knowledge management and feedback systems. Like most programmers, I am usually ready to plow over a lot of PMPs and CMMI zealots that would impose their philosophy of documents beyond reason.

But unfortunately I must stop short... I work for a large consulting firm that provides web solutions for government and you might be surprised at what is implied in that simple statement. It seems that when its taxpayer money, there needs to be a record. When the SEC, the credit card industry security folks, and other regulatory agencies speak - we must simply salute. For the moment, most government agencies are still content that CMMI level 3 is important... as are Cobit, SAS 70, ITIL, and other such quality/governence oriented initiatives/frameworks. Many developers for years have flinched at such concepts... And plenty of organizations have spent time and money chasing these idols, often enough simply because they had to. But as a taxpayer, you might find comfort in real evidence of where your tax dollars go.

Does that mean we programmers simply tuck tail, sulk, moan and complain about all this ugliness? (Ok - maybe a little) With the hours we work and the obvious brilliance in our output, surely we have done enough! And who are these process nazis that question how we go about our work?

The anger and frustration with those who seek to control us... Maybe its ok if we give them a little. The biggest thing we need to do differently is to give them what they need on our terms.

So I am busy at this idea... the concept that execution of reasonable software process can also be "compliant" or "auditable". The idea ultimately is to have metrics happen transparently, to generate audit trails, to do minimum just-in-time documentation, and to basically leverage all that might satisfy the auditors/assessors without imposing significantly on us. The right way to get such "evidence" of process is to have it happen as a side effect. You embed it in your tools, in your automation, in your deployment scripts; To the extent process evidence represents additional ongoing work, it is bad process and it likely can be faked. (Plenty of process "evidence" out there was produced long after the work - being evidence of nothing.)

As I understand it (I wish I had the direct quote), Watts Humphrey (the father of the CMM) was asked some years ago about XP and he suggested that asessors would likely not give it its due... but that was a problem with the assessors, not the method.

One of my pet peeves though is the agile community's complete resistance to producing hard evidence for their case. [How do we sell it to resistant executives and customers, after all? Most have seen their share of silver bullets and snake oil. ] I think it is possible to provide minor documentation and measurement that would satisfy CMMI appraisal and would also stand up to performance critics... and perhaps also allow for review of process and [egads] actual further process improvement. And I think numbers are not so far away if we look for ways to get them... instead of simply thumbing our noses and saying how it hinders our aura. Some of the numbers and evidence of process can occur automatically as we do CI builds... The source control system can probably supply some info... I do believe that design info can be provided without launching into voluminous efforts... so much evidence can be harvested with only minor pain. It may not be what assessors are used to... at that point, I would take things up with the SEI and/or get another assessor who understands the domain of software.

One of the cool tools in my box... I have a little handheld digital recorder that I can dock with my PC and produce text from speech. For other evidence - get a decent digital camera or some such for capturing those cards on the board... or try that new thing at Maybe run the recorder when you do the webex session wth your remote team members.

I do advocate limited process documents - but not printable documentation - just intranet references - maybe on mediawiki or the like... project documents are to list exceptions - the process variations used and limited project-specific info. As far as I am concerned, you need one project plan document, a list of tasks (probably the detailed tasks pulled from the scrum sprint backlog), and perhaps a risk list. [As Eisenhower said - Plans are nothing; planning is everything] Combine this small bit of design and project documentation with archived recordings of the standing meeting... good enough. Evidence does not have to be thick binders of plans and specs and more - that went out of date before it was in the binder.

So I am putting a framework in place... a little intranet portal that supports a range of evidence... as simply as possible. It will highlight any activity that supports an audit or process framework need. [I am sure it will take a little work and ingenuity - but what are my options?] And, if I can help it, when the auditors come we will set them in a conference room with a laptop and they will follow hyperlinks to evidence... no hand-holding and no question that the evidence is real. And the programmers will stay busy coding.

Perhaps I am dreaming though....?

Posted on Sunday, February 11, 2007 11:12 AM | Back to top

Comments on this post: Agile - AND - Auditable ?

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Jeff Smith | Powered by: