Another Thought on Certification

Yesterday at 1DevDayDetroit, Virender Ajmani gave a very interesting talk about Google Map mashups. (If you missed his talk, check out his blog or download his slides.

Besides his very interesting content, he mentioned something that else that caught my attention - the Google Qualified Developer program. It's a different approach to the question of developer certification (which I know is a hot topic in the Agile world in general and at the Agile Skills Project in particular). Google's program is free, and it focuses on accomplishments, references, community participation, and knowledge. If you become certified, you get a badge for your blog.

To be certified in a particular Google API (Chrome extensions, Maps, etc.), a developer must earn at least 3000 of the available 5000 points towards that API in any. She/he can earn points in the following ways:
- showing proof of their work (working code) - up to 1000 points
- providing references (from paying clients) - up to 1000 points
- demonstrate community participation - up to 1000 points
- take the online exam - up to 2000 points

What I like about this approach is that no one type of mastery is enough to earn certification. For instance, a developer who aces the exam can not be certified without other evidence of their competence.

I wonder what an Agile badge in this style would be like.

There are already Scrum exams. Perhaps taking one of them would earn some points. There would be a cap on how many points could be earned through exams, and exam points might expire after a certain time.

I'm not sure how working code is necessarily any indication of someone's skill in Agile, so I think we'd have to come up with something else.

Attending certain classes might be worth points. I know there's been a lot of talk about how taking a class doesn't necessarily mean a person learned anything, and I agree. So perhaps any given class would be only worth a small amount, say 200-300 points, and it would only count if you had taken the course in the past year, and only 1000 points could be earned by attending classes.

Certainly some Agile developers could provide references from customers, and capping the number of points from references would reduce the chance and affect of quid pro quo referrals. Developers who don't have professional references could earn their points in some of the other ways.

And maybe book quests or webinar quests could provide a few points, perhaps with a fairly low cap.

I know there's a non-trivial amount of administration that would be required to manage a program like this. Please join the discussion on the Agile Skills Project Google Group.

Why we say: "No Best Practices"

I came across an great article from 2005 titled: No Best Practices and it reminded me that there was some discussion about the term "best practice" at the recent 1DevDay event.

Besides speaking to reasons why we say there are no best practices, James Bach gives a nice list of "simple, honest alternatives":

• “Here’s what I would recommend for this situation.”
• “Here is a practice I find interesting.”
• “Here is my favorite practice for dealing with {x}.”
• “{Person X} attributes {practice Y} for his success. Maybe you’d like to learn about it.”

as well as a list of answers to common replies to his argument, replies like:

• “I don’t mean ‘best practice’ literally. I’m just suggesting that this is a damn good practice.”
• “When I said this practice is a ‘best practice’ I meant it was best for a certain context. But pretty much everyone in the industry shares that context, so what’s the point of talking about context?”
• “This practice represents a consensus among industry leaders.”
• “Lighten up. It’s just an expression.”

It really helped me get clear about why we say: "No Best Practices".

1DevDay Detroit

Yesterday, I attended a great event, 1DevDay Detroit. It was put on by the Detroit Java User Group, generously hosted at ePrize, and sponsored by too many companies to mention here. The day was amazingly affordable ($40) and, I think, a great success - especially given that it is a new event. There were a few minor hiccups, mainly around timing talks, but they didn't impact the overall quality of the day.

While 1DevDay was not specifically an agile event, there was much agile activity, including:

- Venkat Subramaniam's excellent and funny keynote, "Facts and Fallacies of Everyday Software Development"

- Chet Hendrickson's talk about the Agile Skills Project, a non-commercial group created to quantify skills needed by agile software developers and identify valid means of assessing skills, trainings, and books.

- Nayan Hajratwala's interactive session on refactoring legacy code with no tests and gradually adding and increasing test coverage to the codebase.

There was also a twitter hashtag, #1devday, where participants posted thoughts and comments. Check it out to get a picture of what the day was like.

Just as fun was meeting and talking with other developers, many of whom are using at least some agile practices.

I'm already looking forward to next year's event!