More Agile Certification Talk

I wrote some on this topic, but it is still very popular on the various lists. A blog post I liked was Derick's on the Los Techies Blog. I thought he was very thoughtful and like his comparison with the Master's and PhD thesis defense. That is one thing I was curious about when I submitted my Certified Scrum Practitioner application- would there be follow up and some justification or defense of my answers? Or, would it be rubber stamped? I'm not sure how extensive the review process actually was, but I do know I was never contacted for follow up, just notified of approval.

So, should I feel bad about having my CSP? And mentioning it on my resume? According to Scott Ambler, I should. In his mind, I am ethically liable for the sins committed under the umbrella of a certification program that I don't completely agree with (as I stated in the earlier post). Note- Scott is not against certifications, as this Dr. Dobbs article makes clear, he just has severe issues with certifying "Master's" after a couple of days. While I noted the same concern, I haven't taken the moral position he has. The requirements for each level of certification are publicly available - the Scrum Alliance wasn't perpetrating a hoax on the public or potential employers. HR departments or hiring managers that require a particular certification without understanding the rigor of the certification process are the ones liable for the candidates they hire. Just like I wouldn't blame Microsoft if someone hired an MCAD without validating that they could actually develop applications and hadn't just memorized test answers. Maybe I can gain absolution since I cite the more stringent CSP designation and not just CSM? In Scott's eyes, I doubt it since I'm guessing the self-reported actions on the application are not validated by anyone for quality or effectiveness.

Writing this post, I had multiple tabs open in Firefox that I'd opened over the last couple of days as I saw links in Twitter on the topic. I frequently do this until I have time to go back and actually read the posts. The last tab on this subject was Uncle Bob's reply to Scott's post. I didn't read it yet since I wanted to write out my own thoughts in this post before reading his. I'm happy to see him cite some of the same points I did- the process is transparent and understanding it is the hiring companies responsibility. It is nice when you agree with someone you respect and think highly of!

Finally, here is the Google group where folks are discussing the Agile Developer certification.

What *IS* software anyway?

Goofy question? Not really. Have you ever thought about what software is? Is it just 1's and 0's? Is it just the field where you are paid to toil away in? Is it a product to bring your company wealth and fame? Is it tool there to help others do their jobs, whatever they may be? Understanding that can really have an impact on what we create, how we go about creating it and how usable it is after we deliver it.

One of the valuable resources I've found out on the vastness of the web is the Software Process and Measurement Cast. Despite the unfortunate acronym chosen (SPaMCast? Really? How many people are going to click on a link that says "SPaM"? How many email filters will even let it through?), it is my favorite software related podcasts. Thomas Cagley has really solid guests from across the spectrum, asks good questions and related blog essays on each topic. My favorite episode of all time is Episode 36, which is actually the 2nd part of an interview with Phil Armour. Phil's answer to the question, "Software is not a product. It is a medium, it is a place where we store knowledge."

He explains that there are five such knowledge storing media in the world. They are:

1. DNA - where species store their knowledge
   
2. Brains - a transient knowledge read/write store
   
3. Hardware - he gives an example of a ruler storing the knowledge of length or a WW II bazooka that has the knowledge of how to aim it built into the sighting mechanism.
4. Books - especially the movable typeset books
5. Software - where the knowledge is not just stored, but it is executable. For example, software doesn't teach me to do the computations needed to compute the standard deviation of a set of numbers- it does it.
   

He has a lot more discussion about this but just the concept really made a lot of things click for me. When we think about software being a way to encode (and later execute) knowledge, it makes complete sense why long drawn out projects are doomed to fail. Even IF we could completely capture the requirements correctly at the beginning of a project, what we delivered at the end would still miss the mark. Why? In the intervening time the user would have learned some new things. New knowledge that we didn't encode.

And why do we have such a hard time getting the requirements correct? Because, most of the time, we aren't the ones with the knowledge we're trying encode. And the people with the knowledge don't know how to encode it. It is as if the only way a book could be published is if only publishers knew how to write. You know bass fishing and want to share that knowledge? Fine. Call a publisher, describe what you do and see what they come up with. Maybe, if you're lucky, the publisher will come out to actually see you in action and not just go off your description...or let you read an early draft. Oh, and when the book does come out, you now have to fish exactly the way the book describes it and only that way.

We also, all too often, misunderstand "the way we do it now" with absolute knowledge and encode it with no eye towards allowing it to change in the future once we, or the user learn something more. That doesn't mean coding so that everything is an option. But coding in a test driven style so that we have the confidence to go back and change something later and know we didn't break everything else? Try shifting from Scrum with fixed iteration length to Kanban where you have no time constraint but want buckets for the different areas the work item flows through- can your tracking software handle that?

It also tied in to some of the Real Options thinking. Why do options have value? They are giving you some freedom before you've encoded something, which is then costly to change. Time to get more of the knowledge.

Phil also has a good point about things really taking off when the medium is applied to itself. Like when steam was used to power manufacturing lines to make steam engines. How well do we encode (and execute) the knowledge of how to build good quality software into the building of software? Automated testing and continuous integration tools are a good start, but where else can we apply it?