I don’t think there is a utopia (sorry about that) Note this view from Agile 2008: “ * Assigning vs. Volunteering – HUGE difference and make sure yourMessage 1 of 49 , Aug 6, 2008View Source
Re: [scrumdevelopment] Sprint Planning Resource AllocationI don’t think there is a utopia (sorry about that)
Note this view from Agile 2008:
“ * Assigning vs. Volunteering – HUGE difference and make sure your team members are all volunteering for tasks NOT BEING ASSIGNED THE TASK – it is up to them to pick whatever task off the board they want to take regardless of effort or skill required. If they pick something out of their league it will encourage pairing up to complete the task which produces both cross-training and confidence in the team!
From one of the open space notes on Building Ownership, Accountability and Urgency in a Scrum Team. ( http://www.scrumalliance.org/resources/359)
I guess the old truism “nobody said that it’d be easy” comes in to play – each team and in some ways especially dispersed teams, will have their challenges in this space. It still seems to me that if the gaps are as wide as they are, investing a bit of time to bring the ones who are less advanced to even out the skill balance.
Don’t give up on this – agile is about many things, but in amongst it are principles of individuals and interactions (no I wont trot out the rest...) find ways to give the team the power to select their own work and they will astound you with what they can do
- sounds fluffy, but it is my experience.
On 6/08/08 11:00 PM, "Michael Hedgpeth" <mhedgpeth@...> wrote:
Sorry I let a little bit of "management" speak into the conversation. :)
You said: Then, estimate how long the /team/ will require to do things.
That's exactly what we're doing, but it requires us to know what people are doing what. The conversation in the iteration/sprint goes something like this:
"OK, Michael can do this task in 4 hours, but we probably want him doing this other thing. So do we feel comfortable with Craig doing this task? Is the estimate still valid? OK, Craig, we'll put you down for 6 hours on that since you'll have to get up to speed with that section of the code."
That's what we've been doing for two years and it feels right. But I can't escape the thought that I'm missing out on some agile utopia where everyone picks up the next thing to work on and works as a team, rather than feeling like all they need to accomplish is their tasks.
On Wed, Aug 6, 2008 at 5:52 AM, Ron Jeffries <ronjeffries@...> wrote:
Hello, Michael. On Wednesday, August 6, 2008, at 6:21:14 AM, you
> My team has been following Cohn's "Agile Estimating and Planning" book
> pretty closely for almost two years now. Cohn suggests that you plan a
> sprint in "ideal hours" and not assign a resource to the task; the resources
> self-assign their tasks at the beginning of the iteration.
> Let me ask my question with this scenario: Let's say I'm on a team of three
> people. We have a story, "As a user, I want to log into the system" and
> have identified a "Create the login UI" task. When the team thinks about
> this task, here's how it breaks down:
> Resource 1 would complete the task in 2 hours.
> Resource 2 would complete the task in 8 hours.
> Resource 3 would complete the task in 40 hours.
> I'm being a bit extreme, but on my team we do have quite a bit of disparity
> with experience level.
> It seems that with such a disparity, it's necessary to assign resources
> during sprint planning to put some validity on the estimates. Has anyone
> found a way around this problem? I can only see Cohn's advice as being
> valid for teams of very similar background/experience.
First of all, replace your resources with people. They are much more
useful when it comes to software development.
Then, estimate how long the /team/ will require to do things.
Learn the principle, abide by the principle, and dissolve the principle.
-- Bruce Lee
p. +64 9 914 3100 | d. +64 9 914 3071 | m. +64 21 729 756 | f. +64 9 913 0871
email : richard@... | web : www.quipa.net <http://www.quipa.net/> | Martin Personnel Bldg, Ground Floor | 2 Kalmia St, Greenlane. PO Box 62573, Auckland 1544, New Zealand.
Disclaimer: This email and any attachments may contain confidential information. If you are not the intended recipient, please destroy this email and notify the sender immediately. Any unauthorised copying, disclosure or distribution of the material in this email is strictly forbidden.
... I have never been in that situation, but if I were, I would seriously think about distributed pair programming. Cheers, IljaMessage 49 of 49 , Aug 11, 2008View SourceMichael Hedgpeth wrote:
> Pair programming could work in our situation, however theI have never been in that situation, but if I were, I would seriously
> third team is in another country and has little experience with the
think about distributed pair programming.