Dave Nicolette shared his candid feedback about the first official Certified Scrum Developer course, presented on the Lean Dog boat (Cleveland, Ohio) last week by Ron Jeffries and Chet Hendrickson. Though, he mentioned the learnings and advantages of attending the course but his thoughts did manage to re-ignite the debate about the significance of CSD.
According to Dave, CSD is the first step for software professionals who want to make a personal commitment towards software craftsmanship. The C word would help managers send people to attend these courses and certified developers would be held at a higher professional standard than others. However, Dave was quick to point out the flip side too
When people treat "certification" as a substitute for skills, then it can become a negative thing. There is always a risk that recruiters and hiring managers will come to depend on a given credential to the extent they neglect to verify what they see on candidates' résumés and what they hear in interviews. Those people will dismiss candidates who do not hold the credential.
The first course had its fair set of failures in terms of meeting customer obligations. According to Dave after day one, out of the two teams, first team committed 5 stories and delivered one and the other committed 3 stories and delivered none. As expected, the instructors were not impressed.
Donning their instructor hats, Chet and Ron mentioned that in past presentations of their Agile Developer Skills course (on which the CSD course is based), they haven't seen a worse result; an outcome that truly surprised them, given the composition of this class. It surprised the rest of us, too.
The results were ironic, given that experts were doing the certification. Dave mentioned,
The pendulum had swung to the extreme in both directions in the course of three days. At first, excessive focus on agile technique had allowed stories to remain incomplete. On day three, excessive focus on pushing stories to the "done" column had allowed code quality to suffer. This, from 11 people who already understood the importance of customer collaboration, rapid feedback, incremental delivery, simple design, test-driven development, frequent check-in, continuous integration, and pair programming...11 people who do all these things for a living, and teach others to do them.
The retrospective that Dave and George Dinwiddie did, yielded the following main points
- Agile development is hard. If basic principles are skipped then even experts get easily side tracked
- Insufficient interaction with the product owner
- Technical set-up of developer workstations was problematic, as it always seems to be in hands-on classes and workshops
- The instructors did not provide much guidance about expectations; they may have assumed that with a group of advanced participants
- Participants bent over backward to avoid being opinionated, everyone backed off a bit and let others take a lead in defining the solution
- Everyone's goals for the class were not the same
Most of the retrospective points could be tracked back to inefficient communication.
Tobias Mayer reacted strongly to the process of getting a CSD certificate. He questioned on how the team could get a certificate given that the instructors had a critical opinion about team performance.
Help me to understand how "sitting through" this class for three days to get a CSD is better than "sitting through" a CSM for two days. Neither course seems to have any expectation beyond active participation. Is that all that is required? If so, why knock CSM?...
What qualified each of you to get the certificate, beyond showing up and taking part. Could I have got it if I had done that? I've hardly written a line of code for five years. I would likely have been a very dysfunctional team member. What is the pass criteria?
Dave responded that though some of the points that Tobias mentioned were true, however, the current set of students should not be considered a benchmark sample as the goals for attending the course were different. In the real life, this would not be the case with developers.
Different people had different goals for taking the class. Most didn't think of themselves as "students," exactly, and didn't approach the whole experience in that spirit, although we probably should have. This interfered with the putative goal of the "class teams" to deliver the user stories that were presented.
Tobias added that there is a potential problem in such courses,
Your description here shows the problems inherent in such a course: different agendas and different levels of technical expertize. What is really being taught/tested for on this course? If it is the non-technical stuff, maybe we don't need machines at all. If it is technical then it is outside the Scrum domain. If it is both... well, I wonder if that is wise on a three day course.
Agreeing with Tobias, André Dhondt suggested that as a community we seriously need to look at the value of a certification. He mentioned that some people of the community are trying to do that with the Agile Skills Project.
Hence, though there were some valuable learnings coming back from the first CSD course, however it seemed that the value and the nature of the CSD certification still leaves more questions to be answered.
