On Jeff Sutherland’s “Shock therapy” paper
I read the paper by Jeff Sutherland and others, Shock Therapy: A Bootstrap for a Hyper-Productive Scrum. There are some things I like in this paper, and some things that I don’t.
I like it that
- The coach insists on a proper definition of done, holding the team accountable for the quality of the work.
- The coach insists that only properly expressed stories are inserted in the team backlog. No vague stories, with no acceptance criteria.
- The coach insists that Scrum training is done beforehand, and all parties involved attend, both business and developers.
- The coach insists that all part of Scrum are implemented, with no “scrumbut.” The coach provides reasonable defaults for the (few) degrees of freedom of the Scrum framework.
- The coach works by helping the team solve problems by themselves, with the goal of getting the team to a point where they don’t need the coach anymore.
I don’t like
- The theme of forcefully enforcing the rules that pervades the paper. “Resistance is futile”… Bah.
- Measuring team maturity with velocity alone. Velocity is a highly suspect measure. Velocity depends on the stories estimate numbers, which are decided by the team. There is a part of subjectivity in the estimates. Did they estimate *all* the stories before starting work? Did they change *any* of the estimates later?.
- Velocity is also suspect because it bears no strict relation to return on investment. You might be very fast in developing software that does not give you a iota of profit. This does not seem to be a concern in this paper.
- Thirdly, it’s very easy to be faster than what we did in the first iteration. In my experience, in the first iteration a lot of effort goes in building a “walking skeleton” of the system, learning about the problem domain and project technologies, and so on.
- Fourth, it’s unclear what it means to compare “velocities” of different teams. Who did the estimates that are used to compare velocities? And how do you compare velocities with teams that are not even doing Scrum??
- Then I have issues with how the paper says nonchalantly “ATDD was used” as if practicing ATDD was easy. In my experience, which is also what many trainers say, it takes at least two or three months to begin to be proficient with TDD, let alone ATDD. How much experience and training did the developers have with ATDD? Does the “shock therapy” work well even when the team members are new to TDD and other XP engineering practices?
- No mention is made of the quality of the code produced by the teams. Was the high velocity bought at the expense of introducing technical debt? Was code quality even measured in any way? The paper does not say.
In conclusion, I found a few useful ideas in this paper, but I think it leaves a lot of questions unanswered. I have no problem believing that Jeff Sutherland can achieve very good results with his teams. I find the paper does not prove at all that there is a magic formula that guarantees high productivity.
April 13th, 2010 at 19:59
lot of interesting reflection in this post.
my comment on this
> The theme of forcefully enforcing the rules that pervades the paper. “Resistance is futile”…
scrum gives a lot of freedom to the team (the scrum master is a serving leader with authority only on the process) and scrum set a very small number of rules.
so it looks very strange to me that a team opposes resistance to the few rules instead of using all the huge freedom he has (but it still happen as i noticed).
if you have time would like to hear
what is your opinion about this point ?
and what are your suggestions to deal with these situations ?
April 14th, 2010 at 13:55
Suppose I come to you and ask you to release your software every week. If you are an old school developer, you might answer “My deadline is in 90 days, I will release by then.” Scrum (and XP) have only a few hard rules, but they are not easy to follow.
April 16th, 2010 at 21:13
About comparing velocities of different teams: you simply can’t, end of story, sayonara, bye bye. Each team has different definitions of done, number and experience of team members, different ways to estimate and so on and so forth. You could compare lines of code, but we know that’s not a worthy measure. Or is it? (hint: if you think it is, you’re in the wrong place).
About Scrum rules: I agree with Matteo, they can be very hard to follow, particularly as they would lead to one of the most evident outcomes of Scrum: transparency, definitely something too many developers (in the broad sense) are not used to. Ironically, that also holds true for managers, who have the impression of losing all their control while they are actually taking it back…
Besides, tipically you get answers like “a week? I can’t deliver anything in a week!”. Which is weird, as 90 days are composed by 13 weeks… how can you add nothing to nothing and get working software? It’s the problem of the heap of grain quoted by Fabrizio (http://java.net/blog/fabriziogiudici/archive/2010/04/11/when-bunch-grains-sand-make-heap), just reversed… thus, there is a certain iteration length that lets them actually deliver, so it is only a matter of finding it.
Curiously, if they can’t deliver, the right solution is not to lengthen the iterations, but to shorten them… Scrum goes for 30 days, XP is even more… extreme (the name must has been chosen with a reason, after all!)
April 16th, 2010 at 23:09
ops… a typo in the last sentence…
November 20th, 2010 at 17:50
Hi,
I’m months later and what I’m noticing is few blogs with comments. I think the title and the article ‘shock therapy’ are aimed to get management attention.
When Toyota took over a GM plant with the workers, it didn’t just say “ok go do it the new way”. It retrained and coached continuously. Lots of on the job coaching as the culture at all levels.
Toastmasters has table topics up to 2 minutes – then red light and you’re out. Most speeches are 5-7 minutes, timed, no goofing around times.
If we shake off the shock of the therapy and coach, then the idea of instilling new habits with pro discipline is apt. Riding a bike or golfing or driving a car all need awareness, attention, and kinds of discipline.
bye
vic