Scrum, a framework for agile software development, was recently named by Foote Partners as one of the top IT skills in demand by employers. But companies transitioning to agile, or Scrum in particular, from more traditional methods can sometimes have trouble making the shift smoothly or seeing the expected gains from this more flexible approach. Jeff Sutherland, who built the first Scrum team, coined the phrase and has authored a new book, Scrum: The Art of Doing Twice the Work in Half the Time, recently participated in a Reddit AMA session and provided some good Scrum and agile-related advice.
Here are few key nuggets from Sutherland that I thought would be of interest to those new to Scrum.
The optimal Scrum team size is 5-9
“We find in experience on our Scrum teams at Scrum Inc that as soon as you get more than 5 at the table things slow down. It is noticeably slow at 7 and dysfunctional at 9.”
Use points, not hours, for estimates
“We began teaching in 2006 to abandon hours. They give bad estimates, it takes too long to get them, and it slows teams down. Managers that use them are bad managers and there are a lot of them out there.”
Deal with problems face-to-face
“At Scrum Inc we want always to talk face to face. Often it's Google Hangout. We avoid the phone and avoid email except for information sharing.”
Distributed teams can use Scrum, but there are challenges
“If this is done well, you can overcome the problem that collocated teams are twice as productive as distributed teams. However, the distributed team is constantly struggling to stay focussed on Scrum basics. It is harder to do Scrum well when distributed.”
For more info, see this paper that Sutherland co-authored about using Scrum with a fully distributed team.
Yes, Scrum can be done solo
“I often use a Scrum of one when I have a lot to do and little time to do it. Putting sticky notes on the wall and prioritizing always makes things go twice as fast with half the work.”
The most important point that Sutherland made, in my opinion, which was about agile n general, was that, if you don’t have working software at the end of each sprint, you’re doing it wrong.
“What is hard is to get working product at the end of the sprint. They have bad user stories, they take too much into the sprint, they don't fix bugs immediately when they find them, they don't swarm on stories so they get things done and tested right away, they have no agreed upon way to deal with interruptions, they don't respond to emergencies and coast into failure, and so on. The ways of dysfunction are many but there is only one way to be agile and that is working software with no bugs at the end of a sprint...”
There you go. Good luck with your Scrumming!
Read more of Phil Johnson's #Tech blog and follow the latest IT news at ITworld. Follow Phil on Twitter at @itwphiljohnson. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.