This post originated from an RSS feed registered with Java Buzz
by Geoffrey Wiseman.
Original Post: Rigid Agility: Joel, Agile and Scrum
Feed Title: Furious Purpose
Feed URL: http://www.jroller.com/diathesis/feed/entries/rss
Feed Description: Thoughts and experiences on technology and software.
Rigidity of process and agility aren't necessarily diametrically opposed, but let's start by going a little deeper into what Scrum allows and doesn't. I should probably start by saying that I'm not an expert in Scrum, I'm just an interested bystander.
What Scrum Allows
As far as I know, there's no specific warning against poaching resources from a Scrum team. What it really says is that you can't interfere with a sprint, and the specific example of interference is that you can't change the scope or the goals of the sprint during the sprint. If you feel that the current scope and goals are inadequate, you should terminate the sprint and start a new one.
In spirit, I'd say that Scrum is a process that has a very measured approach to change. A sprint is the atom of planning and implementation for the team. Between each sprint, Scrum has its doors wide open to change: You can set a totally new direction between each sprint if you like, completely re-orient the team. But within the sprint, the doors are largely closed. You've given the team some goals, some scope, and the freedom to plan and implement that work as they see fit.
As far as Scrum is concerned, once you've done that, you should be staying out of the way, letting the team do what it needs to do. If you need to get in the way, if you need to change the goals, the scope, the very foundations of the planning and implementation that's already underway -- then it may be time to consider an abnormal termination of the current sprint and to start a new one with new goals.
Is that a hard line to take? Perhaps, yeah. Some might argue that if you can't live within those constraints, you shouldn't use that process. But practically speaking, can a sprint survive a momentary re-routing of a resource? Yes, I think it can, both in letter and in spirit.
Myself, if I were to interpret the spirit of Scrum around the sprint, I'd say that the team should make the decision about abnormal termination - when in-sprint changes arise, the team should have the freedom to argue that the proposed change compromises their sprint. So if you need to borrow Joe for a day, the team might decide that doesn't breach the goals. On the other hand, if you need both Steve and Yakov for a week, we can't meet our goals, and we'll require a sprint termination.
Real World Examples
That said, I haven't applied Scrum to a real project, so perhaps others can chime in and explain how this idea of unchanging sprints has worked (or not worked) for them.