Technical Excellence in Scrum

Jeff Sutherland recently posted a message on the Scrum Development Yahoo Group regarding Scrum and Technical Debt.  Jeff mentioned why Scrum eschewed technical practices, specifically:

In 1995, Kent Beck asked me for everything on Scrum.  In a famous email he said he wanted to use everything he could and not reinvent the wheel.  The first Scrum team was doing all the XP practices in some form.  However, in 1995 when Ken Schwaber and I started rolling out Scrum to the industry, Ken though [sic] we should focus on the framework as it would lead to more rapid adoption and teams should use the impediment list to bring in the engineering practices as needed.

I applaud Jeff for saying this, and one certainly can't argue with Ken's assertion that avoiding technical practices would lead to more rapid adoption.  I would argue, though, that very few teams use the impediment list as a means for improving their technical practices on an as needed basis.  In my own coaching experience, that number is painfully close to 0.

Jeff goes on to call out the coaching and training community:

At Snowbird this year, Agile leaders from all over the world convened to do a retrospective on 10 Years Agile. The prime directive that was unanimously agree upon by all present was that in the next tens years Agile leaders must Demand Technical Excellence. Failure to do that means you are not an Agile leader. We are sloppy in our coaching and training. If stuff is not done and/or has bugs at the end of the sprint, the team is not showing technical excellence and is not agile. We need to be clear about that.

And:

One of the reasons we have so much technical debt is Agile leaders are not coaching and training well enough.

I suppose that from a results-based view, Jeff is right.  We obviously aren't coaching and training well enough.  However, I don't feel that's universally the case, and I've certainly pushed for technical excellence since I first started telling others about XP in 2001.

I responded to Jeff, venting some of my own frustation in the process.  Here is that response:

Hello Jeff,

I agree 100% with everything you say on this topic except, "...Agile leaders must Demand Technical Excellence. Failure to do that means you are not an Agile leader. We are sloppy in our coaching and training."

If I had a dollar for all of the times I have pointed out practices that were contributing to technical debt, I could take a very nice vacation.  If you add the number of times I've shown practices (through demos, pairing, etc.) that help reduce technical debt, I could extend that vacation significantly.  If you add the number of times I have received the "we don't have time" excuse, despite my pleas to consider all of the issues leading to debt as impediments, I'd be getting into early retirement territory.

I learned "Agile" from XP back in 2000.  Prior to that I did what I could to achieve technical excellence.  The XP technical practices, most importantly TDD, improved my level of excellence considerably, and I've been teaching those practices ever since.  I'm constantly astounded by the number of supposedly competent software developers who don't believe that writing any automated tests for their code is worthwhile, let alone using a practice like TDD.  I have repeatedly shown how TDD results in simpler, more robust code, and yet there is still a huge amount of skepticism about the practice.  Don't get me started on Pair Programming.

I have beaten myself up many times thinking that I'm not coaching well since the people with whom I'm working aren't using these practices, and don't see the value despite their velocity eroding after a half-dozen sprints or so.  I've beaten myself up when these teams don't think it's a big deal when backlog items aren't complete at the end of a sprint, despite my advice to simply finish what can be finished to the DoD and use the Retrospective to figure out why some items weren't completed.  I've beaten myself up when teams don't listen to my advice about ensuring that all of the team members are on the team 100% of their time, and people get pulled away and not all items are completed in a sprint.

Frankly, I'm tired of beating myself up when people don't want to listen, but that's a different issue.

Over the past few weeks I've done a lot of soul searching with respect to my work as a coach, discussing it with other people ranging from my wife to the original XP Coach himself.  I'm by no means perfect, but my conscience is clear when I say that I have NOT been sloppy in my coaching and training.  I have busted my ass trying to get people to adopt the types of practices that will lead them to technical excellence.

I suppose you can lead a person to knowledge, but you can't make him think.