Scrum, Technical Practice, and the CSD

Before we joined the dark side and became Certified Scrum Trainers ;-), we spent much of the previous five years working with Scrum teams that found they weren't able to meet their commitments.  The story was usually the same: the end of the sprint came and the development team hadn't finished all the work they had promised.  They had tried reducing the quantity of work they committed to each sprint, but still no luck.  The problem was not the number or size of the User Stories they took on each sprint, but something in their code and how they worked with it was holding them back.

Just as the problem was consistent from team to team, our solutions were often the same.  We had them shorten their one month sprints to two weeks;  we worked with the Product Owner to split their stories into small chunks;  we moved the QA process from the end of the sprint to the beginning.

These changes made some things better and some other things worse.   This was our plan.

As we all know, Scrum works by exposing the impediments in our processes, by shoving them in our face so we have no choice but to do something about them.

The impediment we often find and the one we expose by shortening the sprint length is the development team's lack of good technical practices.  Without good technical practices, we must wait longer to learn about the bug we just added to the code; we wait longer to discover our design is slipping away from us; we become afraid to change bits of the system that we didn't write and sometimes, bits we did.

These problems are not new.  The solutions are not new.  But, they are not the problems that Scrum was originally designed to directly address. 

Their solutions can be found in Extreme Programming, so it was natural that when the Scrum Alliance sought to help Scrum teams find them they turned to some XPers.  The solutions we brought became the learning objectives for the Certified Scrum Developer rating.  For those of you unfamiliar with the CSD, it has been around for about a year and occupies a place slightly above the CSM in the hierarchy of SA certifications.  Getting the CSD requires five days of training. Usually this takes the form of a standard CSM course and a three day 'basic developer skills' course.

The 'basic developer skills' course--ours is called Agile Developer Skills while other folk’s courses have other names--is a hands-on course.  Today, our courses are mostly focused on programmers, but we have a tester focused course in the pipeline.  Participants in these courses will be taught the basics of Test-Driven Development, Simple Design, Acceptance Test-Driven Development, Refactoring, Pair Programming, and Continuous Integration.  Our course does this by interweaving lecture, demonstration,  and a laboratory project.  We wrap all this together with demos, retrospectives, and instructor review of code and technique.

Like the other certification courses, CSM and CSPO, it is important to remember that the basic skills courses are a starting place.  Bob Martin said this quite well in his recent article about the Craftsmanship movement.   
 
We believe that in order to be successful, members of Scrum Dev Teams must have these skills.  While the CSD route is not the only way to achieve them, it is a good starting place.  These courses are now beginning to be available, not just from Ron and Chet, but from many Scrum Alliance Registered Education Providers.  If you find your Dev Teams are having difficulty getting to Done, it may be the solution you are looking for.