16 September 2011

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.

4 comments:

ullizee said...

Dave, great personal story. And quite recognizable for someone started out with extreme programming in 2003, and only added Scrum later on, and thus keeping the core technical practices in the approach. But when sailing off to other environments I had the same experiences as you on lack of interest in technical excellence.
:) Quite sure Jeff wasn't aiming at you personally.
And Ken told me he had hoped that extreme programming in itself was strong enough and compatibility with Scrum would have been so obvious that... Well, it wasn't. He has anyhow launched great programs on this topic with the PSD classes.
Keep up the good work!

Martin Wickman said...

I feel your pain. I always reasoned that, if, despite all your efforts, the team/organization cheats on technical excellence, skipping stuff in the heat of deadlines and when their technical debt skyrockets because of that and they still ignores their methods, then that is of their own choice.

In the end, we cannot force anyone to do anything and sometimes we just have to accept that. Hard as it may be.

Dave Rooney said...

@Martin,

I agree. I find it tough to be paid what I'm paid to coach, only to have people decide that they don't want to heed my advice. Yes, I realize that my attitude isn't very Weinberg-ian, but I'm working on it.

I personally know well over a dozen coaches who have gripes similar to mine. That's why I took issue with Jeff Sutherland's statement that we aren't coaching very well.

I know that *I* am trying to help teams achieve technical excellence, and I know many other coaches doing the same. They are all doing the same thing - if the people don't want to listen, then there isn't much you can do. I agree to an extent... you *can* keep pushing.

I just hope that I don't become too cynical to care enough to keep pushing.

Matthias Marschall said...

I'm personally struggling with finding out why engineers are readily accepting technical dept all the time.

As I'm working mainly as an agile leader I'm able to give my own teams room for technical excellence. They are pretty thankful that I give them the time and the re-assurance they need to do what's necessary.

But when I look at teams I consult it's a totally different picture - exactly like you describe.

So maybe when coaching teams we've to look more at the value system of the whole organization in which the teams operate. If management is only pushing for new features and not giving room for technical excellence, the teams are doomed. I fear we need to change the end-to-end process of value creation in a company. Only trying to optimize one part in that process (the development team) seems not to be enough :-(