A few of you may know that the first ever Certified Scrum Developer course taught by Ron Jeffries and Chet Hendrickson was held the first week of May in Cleveland, OH. A couple of those may also know that I attended along with a handful of well respected coaches (George Dinwiddie, John Kern, Jeff “Cheezy” Morgan, Paul Nelson, and Dave Nicolette) and some other Agile developers from all around. It was an interesting class and I think an exciting move forward for our community.

There is a lot of confusion and opinion around the idea of developer certification, much of it justified. I think that Ron and Chet have effectively taken the high road on this. On one hand, they have bowed to its inevitability and decided to become the first to attempt to do it well in the context of Agile and Scrum. On the other hand, they have done their best to make sure that the course is uncompromising in showing what it is really like to work on an Scrum team following a disciplined engineering approach.

In this last regard I feel that they have been quite successful. The course was, in many ways, identical to many real projects that I have participated in except for the absurdly abbreviated schedule (Necessary to fit the experience into just three days.) It was even effective in presenting some of the usual problems: set up problems, communications problems, arriving at shared expectations, etc. What was interesting (and enlightening, and mildly entertaining…) was that even this highly experienced group of attendees couldn’t avoid some well known problems including ones that we coach teams every day to avoid.

Too many cooks spoil the broth, or so the old adage goes. It seems that maybe too many coaches spoil the product as well. One of the interesting and unforeseen consequences of having so many highly experienced people work together is that we didn’t appear to be as effective as we might have expected.

There are a number of likely reasons for that. For one thing, I think we all wanted to give due respect to our peers, who we knew by reputation but had never worked with before. For many of us, myself included, it would have been more usual to take a strong, principled stance on certain issues, but instead we may have tried too hard to just get along. I think there was also a tendency for the coaches to coach instead of just getting stories done. In a real project these sorts of team dynamics would work themselves out over time, but in the short time allotted we had only begun to gel as a team.

Overall, it was a great experience. I met some cool people, and had a lot of fun slinging Java code with them using TDD, pair programming, and continuous integration through and through. I hope that everyone gets the opportunity to experience this course and find out what the whole XP/”engineering practices” hoopla is all about. Hopefully, BigVisible will soon be involved in making that happen.