The Artima Developer Community
Sponsored Link

Java Buzz Forum
Rigid Agility: Joel, Agile and Scrum

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Geoffrey Wiseman

Posts: 51
Nickname: diathesis
Registered: Aug, 2003

Geoffrey Wiseman is a software professional.
Rigid Agility: Joel, Agile and Scrum Posted: Nov 16, 2006 9:57 AM
Reply to this message Reply

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:
Feed Description: Thoughts and experiences on technology and software.
Latest Java Buzz Posts
Latest Java Buzz Posts by Geoffrey Wiseman
Latest Posts From Furious Purpose


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.

My Interpretation
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.

Read: Rigid Agility: Joel, Agile and Scrum

Topic: GPL'ed Java Previous Topic   Next Topic Topic: The London 2.0 Website��Cometh

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use