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.

Scrum Developer Certification is Now Real

Just over a week ago, I got the following email from Chet Hendrickson:

Hello ADS Course Participants,

The mechanism for applying for the Scrum Alliance Scrum
Developer Certification is now available. The Agile Developer
Skills course you took with us satisfies the Basic Developer Skills
portion of the certification requirement. If you also hold a
Certified ScrumMaster (CSM) certification you may now apply for the
CSD.

The application can be found at:
http://www.scrumalliance.org/resources/1809

So whatever your view about the value of certification, it's happening. As for me, I'm not a CSM, so I won't be applying for a CSD any time soon.

Thoughts on my experiences at the second Scrum Alliance CSD course.

Dave Nicolette recently blogged about how he has joined the ranks of the Certified Scrum Developers, by being a CSM and completing the Scrum Alliance CSD course taught in Cleveland by Ron Jeffries and Chet Hendrickson. I took the same course one week later in Ann Arbor. Unlike Dave, I'm not a CSM yet, so I don't qualify as a Certified Scrum Developer - I'm not going to weigh in on the pros and cons of "certification".

Even though the CSM was offered the two days immediately before the CSD course, I chose to only take the CSD course right now. My current focus is on improving my development skills, and the CSD course fits right in with that. It was a great opportunity to practice TDD, Pair Programming, and Scrum under Ron and Chet's observing eyes.

Unlike the Cleveland class, the Ann Arbor only had a few "known" participants. Present were Rich Garzaniti, a long-time eXtreme Programmer and member of the Chrysler Comprehensive Compensation project (C3) and Nayan Hajratwala, agile and lean coach and speaker. Dianne Marsh, co-founder of SRT Solutions, was also present, although she does not specifically focus her work on agile. The rest of us are seasoned developers with agile experience that ranged from never having done TDD to actively learning TDD outside of work and in the early stages of trying to introduce small agile practices into their workplace. I'm a long-time developer, involved in the Agile Skills Project, a rabid Code Retreat attendee, but I have little agile experience on the job.

Like the Cleveland class, we had difficulty with infrastructure that held us back, and as Dave said, that's not unexpected. Still, one team spent basically an entire 4-hour iteration (the course only scheduled 3 iterations in all) on infrastructure problems. The team I was on only spent half of an iteration on infrastructure problems (Without Nayan's familiarity with Maven, Hudson, Eclipse, and FitNesse, I suspect it would have also taken us a whole iteration too). In our class retrospective, we decided that there was some merit in having infrastructure issues as part of the class, as it gives a taste of what it really takes to set up tools for an agile project. We also decided that whatever steps are taken to reduce such issues, there will always be some, and they may provide enough learning.

In contrast to Ron's assessment that the Cleveland class produced the least results he'd ever seen (the CSD course is based on Ron & Chet's ADS course), Ron said that we, the Ann Arbor class produced the most "done" code he'd ever seen. In Dave's blog post, he gives an extended analysis of his class's results. I won't be discussing our results in that level of detail. Briefly, I attribute our success to having executed agile practices well. Here is a list of some things I think we did well:

• Sprint planning meetings that involved a PO
• TDD that focused on results and had a good balance of strong assertions and deferring to the other partner
• Frequent Pair Rotation
• Communication between pairs
• Hourly Standup Meetings (remember, iterations were 4 hours)
• Retrospectives that produced actual to-do items for improving our process
• Doing the things from our retrospectives that we said we'd do
• Lots of time with Ron & Chet as POs.

While we certainly were not immune from making assumptions about stories, we did ask a lot of questions about the cards during our planning meetings. When the Ron or Chet gave high priority to stories that we thought would take a lot of time, we suggested other stories that we thought would generate some value more quickly or we requested that some stories be split. We were conservative with our commitments.

Additionally, I think the goals the Ann Arbor participants had for the class were well suited to creating "done" stories. While I think Rich and Nayan wanted to refine their already strong agile craft, the rest of us seemed to be experienced developers who either want to become agile or to become more agile. While Nayan seemed to play a dual role as contributing developer and coach on my team, I think we all took responsibility for delivering quality results and improving our process.

All of that is not to say that we didn't have our share of problems. We realized late in the course that we would have saved some time talking in circles if we had drawn simple design ideas on a white board. Additionally, my team might have been able to show more value to the POs if we had implemented fewer file operations and left IO as an abstraction. In our code review, our team found some early design decisions that would have caused difficulties later, were we to have continued developing the product.


There's an old saw that says we learn more from failure than we do from success. That feels true for me regarding this course. I'm struggling to find any real "gems" of learning. For me, the biggest benefit of the course was the practicing - practicing technical tasks and practicing improving our process. Since I don't pair at my current job, the course gave me a good chance to look at how I pair and think about ways that I can be a better pair. And I did learn to use FitNesse and Hudson, which I had not used before.

And finally, I left the class with a renewed hope for our profession and my career. Being in a class of developers who seem really committed to delivering value and improving their craft was tonic for the pain and exasperation that I've experienced in past projects that had all the classic failures.