Scrum, Technical Practice, and the CSD

7 March 2011

Chet Hendrickson
Richard Chet Hendrickson, LLC

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.

Article Rating

Current rating: 5 (1 ratings)

Comments

Philip Borgnes, CSM, 3/8/2011 4:50:09 PM
This is interesting to me because I just had this experience with a young team (in age and experience) helping them adopt Scrum into their development. We found, just as you did, that the team didn't quite finish the stories defined by the Product Owner even when we adjusted to shorter sprints and story downsizing. The solution as you stated was to start reducing our technical debt by removing a person from the team and moving to XP. This helped quite a bit and enabled us to not only complete all the stories, but pull in additional work from the backlog after a few iterations of making these changes. Needless to say the team was very happy.
James Peckham, CSP,CSM,CSPO, 3/23/2011 3:36:10 PM
I find it strange that implementations of scrum don't acknowledge that scrum is ONLY a project management framework and that good technical practices must also be incorporated. Despite that being one of the first things you learn in CSM classes.

Then even when they do acknowledge it they have a hard time executing it. I do not know if CSD will address the root cause of the issue... which I believe is the lack of mentor/apprentice relationships within organizational structures.

I hope it will. I would encourage every technical lead who is involved in scrum to study Extreme Programming. If the CSD teaches XP in practice... I would support that.

However, why call it "Scrum" developer??? That confuses me...

Andrej Ruckij, CSM, 4/13/2011 5:49:37 PM
Agree with James. I think that Scrum only highlights the need of different and more sophisticated development practices in order to be able to work in such dynamic environment.
And all these practices are not related to Scrum directly.
Scrum developer sounds really funny :) What is next? - Scrum QA? :)
Tim Cawte, CSM, 6/15/2011 5:23:57 AM
I thought Scrum Developer was a good name for it, I guess you could change it to Scrum for the Developer?
Dr. Sanjeev Raman, PMI-ACP, SAFe Agilist, CSP,CSM,CSD,CSPO, 6/16/2012 12:22:10 AM
Good article. It will be interesting to see in the future how distributed dev teams will work with the Scrum framework - given the new tools and platforms to support development.

You must Login or Signup to comment.