One of the perennial questions that development teams face is the struggle to staff a full time technical writer. Of course, I have an opinion on this…but I was quite stricken by Kenneth S. Rubin’s analysis of this very question in his book, Essential Scrum. He frames the discussion in the context of cost-of-delay calculations, and the difference between idle work and idle workers. Consider:
(more…)
Scrum, Idle Work, and Idle Workers
From Essential Scrum by Kenneth S. Rubin:
Idle work is work that we want to do (such as building or testing something) but can’t do because something is preventing us. […] Many product development organizations focus more on eliminating the waste of idle workers than on the waste of idle work. […] In Scrum, we are acutely aware that finding the bottlenecks in the flow of work and focusing our efforts on eliminating them is a far more economically sensible activity than trying to keep everyone 100% busy.
Scrum Makes Problems Visible
Lots of organizations think “Scrum fixes problems,” and are then surprised that when they try to implement Scrum, all they see are all sorts of problems. Frequently this is used as justification for giving up, or claiming, “It doesn’t work!”
Scrum doesn’t fix problems. Teams do. Scrum makes problems visible so that teams can fix them.
The Trouble With Being On Two Teams
The trouble with being on two teams is that you wind up being on none.
