"Badges? We don't need no stinkin' badges!" - Blazing Saddles, 1974

I became a "Microsoft Certified Professional" (MCP) for .Net back in '03, got my MCP for WPF last summer, and just picked up a Certified ScrumMaster (CSM) badge, all of which means... SQUAT!

Any experienced developer can tell you an MCP certificate (or a CS degree) says absolutely NOTHING about whether someone can actually write production quality code or help a company ship products, and there's been some criticism over the way the term "Certified ScrumMaster" is sometimes promoted and abused. For the record, a Microsoft certification essentially proves you can memorize API trivia out of a study guide, and a CSM certification just says you've had two days of classroom exposure to the basic concepts of Scrum.

Of course, there's a LITTLE more to it than that. A Microsoft certification guarantees baseline familiarity with the recommended way to handle common Windows dev. tasks, and a CSM badge guarantees exposure to fundamental Agile concepts, along with a general idea of how to apply them, and obviously indicates a commitment to helping to refine a company's development process. When interviewing new hire candidates at my last three companies, I always asked about certification as evidence of some level of "devotion to craft", beyond simply working on "assigned features", but I was always more impressed if the candidate was familiar with notable developer community authors, or attended local dev. events.

From the job candidate perspective, certification is most useful in helping get past HR and other non-programming middle manager filters. From management's perspective, the risk in being overly impressed by a Microsoft certification is alot less than the risk of turning an inexperienced CSM loose on your enterprise organization's development process for your mission critical software. CSM training and resources often have a kind of naive idealism to them ("Let's play a game to illustrate collaboration!"), and I think a CSM who hasn't personally experienced harsh corporate realities is in danger of having management and technical staff quickly flip the "Bozo Bit" on them. For example, there's a HUGE difference in promoting "self-organizing teams" in an environment of top-notch, experienced, highly-motivated developers, versus in a bloated, complacent, corporate development environment.

I've been keeping up with Agile practices and approaches since the late '90's, and I'm currently most impressed by approaches that combine Scrum and Kanban, as described in Henrik Kniberg's newly-published "Kanban and Scrum, Making The Most of Both". The book is succinct and the clearest explanation I've come accross, of what all this "Kanban" stuff is that everyone keeps talking about, and how it relates to Scrum

Update (2/13): Scrum co-creator Ken Schwaber recently parted ways with the Scrum Alliance, and started Scrum.org to offer more rigorous developer training.