Re: [scrumdevelopment] Swarming, I just don't get it.
- I don't mind having the stories ordered in the sprint backlog by PO-determined priority, but I think the team should have free rein to work on them in slightly different orders if it makes sense. However, if the team does this, and a "top priority" story is unfinished at the end of the sprint, while lower ones are completed, then the team will have egg on their face - more so than if they had alternatively just failed to finish the lowest priority story. :-)
-- StephenOn Mon, Jan 3, 2011 at 9:00 PM, Alan Dayley <alandd@...> wrote:
Exactly! You describe swarming as it should be, something that happens naturally, day-to-day. My example scenario was for the purpose of making a reason for swarming obvious.Good to have the PO pick falling out stories.So, I'm going to assume the answer to my prioritization question is:- No priority to stories in the current sprint. Rely on the Product Owner to guide such decisions when necessary.- The Product Owner sets priority in the Product Backlog, as manifest by what stories are brought to the Sprint Planning meeting.Does that sound about right?Learning the nuances is good!AlanOn Mon, Jan 3, 2011 at 9:27 PM, Stephen Bobick <sbobick2@...> wrote:"I do not mean to imply that having a story incomplete at the end of the sprint is to be expected or normal. Nor does swarming on story 1 necessarily mean that stories 5 and 6 are abandoned. In my experience, swarming will both solve a problem quickly and happen will before the first half of the sprint, as in my made up situation."
If a story is taking longer than estimated (a 3 pt story is turning into a 5 or 8 pt story), then, at the daily scrum where this is identified as occurring, the team decides if a second (or third.... or more) person should jump onto the story to get it done faster.
If you are approaching the end of the sprint and some team members are finishing and others are not done with stories in progress, then the "free" members should help out with the partial stories rather than pull stuff from the backlog.
I see the scenario of swarming early in the sprint in a "prioritized order" as being something that should be done/be necessary reallly rarely."Half-way through the sprint, two team members become very ill and cannot work for several days. Obviously, all the stories probably cannot be completed. Only 4 of 6 stories will be completed in the sprint. On what basis does the team choose the 2 stories that will not be done? "At the daily standup this is identified as a risk and the ScrumMaster informs the PO that the sprint is in jeopardy. The sprint is either canceled, or stories are removed (the PO decides which stories to remove)My $.02-- Stephen
On Mon, Jan 3, 2011 at 8:14 PM, Alan Dayley <alandd@...> wrote:
I do not mean to imply that having a story incomplete at the end of the sprint is to be expected or normal. Nor does swarming on story 1 necessarily mean that stories 5 and 6 are abandoned. In my experience, swarming will both solve a problem quickly and happen will before the first half of the sprint, as in my made up situation.Are you recommending that stories not be prioritized? If so, would that be just in the sprint or in the release or in the entire backlog?Different scenario:Half-way through the sprint, two team members become very ill and cannot work for several days. Obviously, all the stories probably cannot be completed. Only 4 of 6 stories will be completed in the sprint. On what basis does the team choose the 2 stories that will not be done?This is good discussion.AlanOn Mon, Jan 3, 2011 at 8:37 PM, Stephen Bobick <sbobick2@...> wrote:" Because if a story is not complete at the end of the sprint, it should NOT be story 1, the most important story. "ALL stories should be done at the end of the sprint. The team doesn't commit to stories 1 to n where n < 6, they commit to stories 1-6.
This idea of a total ordering of priorities tends to lead to inefficiencies that are worrisome, not to mention the premise up front that stories may "not get done".
Just my $.02
-- StephenOn Mon, Jan 3, 2011 at 7:14 PM, Alan Dayley <alandd@...> wrote:
Here is a simple "best use" of swarming.Conditions:- Team of 8 people- Two week sprints
- 6 stories in the sprint- Story 1 is highest priority, 2 next priority, and so on till the 6th as lowest priority in this sprintCondition after one week:- Story 1 is not yet finished- Story 2 and 3 are finished- Story 4 and 5 are startedSwarm: The people working story 5, and maybe those on story 4 should stop and go help with story 1. Because if a story is not complete at the end of the sprint, it should NOT be story 1, the most important story. How can the swarmers help?- By writing documentation- By pairing with the people already working- By writing tests- By testing deeper on the problem- By going to talk to managers or vendors or whoever can solve a blocking issue- By bringing lunch in to the people working on story 1- By reviewing code- By discussing the impediment from a different point of view- By whatever!Coding is not the only way someone can help with a blocking problem. It shows maturity when a developer can drop "his task" and go help with "someone else's problem" by doing that which may be "menial" for team members who are stuck.AlanOn Mon, Jan 3, 2011 at 1:33 PM, agilejedi <agilejedi@...> wrote:
The use of the bee as a metaphor for industry is well founded. Work together, help each other, etc..., is all common sense.
I don't get how swarming is some rite of passage and when you see your SCRUM teaming swarming you know they have arrived.
I don't see how having the entire team working on the same story is generally the best approach.
I recognize that the practice of pair programming in XP has been a hard pill to swallow but now we have whole team programming? Is that what this really is?
The premise that the quality of the design, architecture, and code will be lifted up by the sum of everyone's capability is not generally true. There are times when the results become more mediocre with the increase in participants.
For example, I have seen using generics banned because the majority of the developers did not understand how to read the syntax.
I have seen what I have deemed the best proposal removed from the possible solution set just because the person was tired of arguing with the vocal, big mouthed, team idiot. (I know, I should say what I really feel and stop holding back.)
It is not proven that two minds are better than one. But it may be proven that given any two minds one is better than the other.
The idea that a developer working alone will rapidly loose motivation is not a fact either. I have often lost motivation when being saddled with a hard headed developer that should consider a new career, but hey, we can't say that, everyone is valued.
Now, if swarming is just the new term to mean:
- Divide up a product into features, features into tasks, and tasks into sub-tasks, and let's work together to take advantage of parallel effort...
- Communicate with knowledgeable people and get new ideas
- Keep the saw sharp
- Work together to help avoid human faults such as forgetfulness, being distracted, etc.
- basically so all good things we could do to develop software with none of the bad things
- When the code has someone's life on the line get another pair of eyes on it, maybe even do a formal review, or use a very tight process heavy approach.
Maybe management would like developers to be like bees. We all work in our roles, all roles work synergistic-ally to the benefit of the whole, and we will never want to change our role, our position, leave the hive, serve a new queen, become the queen, or get a little personal recognition, because we are not people, we are bees.
Sorry, I don't get it.
- Hello, Seyit.
Very well put! Thanks!
On Friday, January 7, 2011, at 6:17:36 AM, you
> Wouldn't you think if team used swarming "in a right fashion" (what ever itRon Jeffries
> 1. Majorty might learn how to read the syntax of generics,
> 2. "The vocal, big mouthed, team idiot", might realize he's not the boss and
> should get well with the whole team or he needs to get the .... out,
> 3. The lesser mind can learn something from the better one.
> My team doesn't use swarming and also I don't have any first hand experience
> on that. But considering the examples you have, and definition of swarming,
> it seems actually teams you describe might give it a try.
> Proposition 1: Two minds are always better than one, if they are combined in
> the right fashion. So you might be doing it wrong.
> Proposition 2: Given two minds, it's not proven there exists a pattern to
> find which one is better. So it doesn't matter if one is better than the
Know what I pray for? The strength to change what I can, the inability to
accept what I can't and the incapacity to tell the difference. --Calvin and Hobbes