I was in this position once upon a time, abd the lessons that I learned about selecting a 3rd party package basically boiled down to:

1. Ensure that you have a very thorough demonstration of the packaged software, at which you ask how the package does the things that you see as being important to you.

2. Do not spend time telling the salesman how you do things ... that just lets them off the hook as they quietly listen to you wasting your time and not screwing them down to details and they will always agree that their software will do that just perfectly.

3. Determine how much you are willing to change your ways to accommodate the way the package does things. This is very important.

4. It is not especially relevant, in my view, how many other people use the software ... that is current installations. A new software package may very well be the best of product, but yet have little following due to it being newly available in the marketplace.

5. A Package under $1,000 will probably be great, and do what packages under $1,000 do, but I almost guarantee it's not for you/.

Well, I could go on with lots of wordly wisdom that just supports the view that you better know what that package does before you commit, and you better know what it doesn't do before you commit.

And for really expensive packages, there is no reason to believe that it is the cheapest option. I could grow a lot of watermelon in my own garden for $1,000,000 plus. Beyond that, Mark's option a is pretty standard stuff, and very common.

And finally, regardless of any option, estimates will always be guesses, and when managers ask for comparative estimates, you can bet your bum that they are looking for solid figure that they can beat you with and hide behind when it proves to be incorrect, as it will inevitabley, indubitably and definitely be.

Regards,
Roy Morien

---

To: scrumdevelopment@yahoogroups.com
From: woyna@...
Date: Fri, 31 Dec 2010 15:43:30 +0000
Subject: [scrumdevelopment] Re: How to estimate the project with scrum

 

My experience has taught me that a) building it yourself will always be harder, and take much longer than you expect, and b) software salesmen are basically lying weasels, and the software you purchase will not do 50% of what you want it to do, resulting in you living with the limitations, or reverting to option 'a'. :-)

So, the estimation process is really no different. For option 'a', you use the techniques described in this thread to generate a number, and then multiply it by 2 or 3.

For option 'b', take the cost of the acquired software, and multiply it by 2 or 3.

Mark

--- In scrumdevelopment@yahoogroups.com, "toomuch2do914" <lynn.cowan@...> wrote:
>
>
>
> Any insight into how to approach project estimation when the PO is asking, "Should we buy it or should we build it?" There are two epics here: one for the effort to integrate some TBD purchased product with ours and another for building a similar product and integrating it with the rest of our product. Any case studies of how someone using scrum has successfully worked through this? Thanks.
>
> --- In scrumdevelopment@yahoogroups.com, "Markus Gaertner"<shino@> wrote:
> >
> > Scrum states that the product owner is responsible to take care of having a Product Backlog which is prioritized and estimated most of the time. The contents of the Product Backlog include user stories which might be on a more coarse level like epics, or finer levels which can be pulled into the next iteration. From this perspective you should have an emergent backlog of stories that you want to work on with some stories ready to go, and others on the shelf where you need new information in order to start working on them - i.e. acceptance criteria.
> >
> > Epics are usually on a coarse level of confidence regarding their estimates. They are broken down later into finer stories. The sum of the estimates of the stories often does not map to the estimates of the epic. They are usually larger or smaller, thereby incorporating the knowledge that was gained in the meantime, and reflects the purpose of estimation: To get a hunch about the size of your project.
> >
> > Now, there are two common scenarios for projects with Scrum. Either your scope is fixed, then you should be able to negotiate about the time you will be able to deliver the functionality. The story estimates will give you an overview and together with your current velocity you can extrapolate different delivery dates based upon the certainty you have in your story estimates.
> >
> > The second scenario is to get get a something finished at some point in time. Then you can extrapolate from your backlog what functionality is likely to be finished by then - again using your story estimates together with your team's velocity. Apply varying factors of uncertainty to make pessimistic and optimistic estimations about which features will be included in that release at that point.
> >
> > Since all your team members are working fulltime on your project, you will either have a fixed time - which is easy to calculate the project personnel costs for - or you will have a variable project delivery time. In the second case, you use your optimistic and pessimistic estimations, and calculate your costs accordingly.
> >
> > Agile Estimation and Planning from Mike Cohn elaborates on this topic.
> >
> > Best
> > Markus Gaertner
> > http://blog.shino.de
> > Twitter: @mgaertne
> >
> >
> > ----- Original Message -----
> > From: mchlsync@
> > To: scrumdevelopment@yahoogroups.com
> > Date: 30.12.2010 03:37:43
> > Subject: [scrumdevelopment] How to estimate the project with scrum
> >
> >
> > > Hello,
> > >
> > > I have a few questions related to the Scrum estimation.
> > >
> > > 1. Why doesn't Scrum allow us to have a detailed task under user story in
> > > backlog? The only way to create the task is that we need to move the user
> > > story to the sprint and then we can create the tasks for the user story.
> > >
> > > 2. I heard that we should not estimate more than one or two sprints because
> > > we will have to change them later. But it doesn't really work in reality. We
> > > need to estimate the whole project or a few features in advance so we can
> > > negotiate the target date and adjust/prioritize the features. In order to
> > > estimate more accurately, we need to break down the user story into the task
> > > before creating the sprint. How should I handle or estimate for that?
> > >
> > > Basically, how can we estimate the timeline for large project or large
> > > features? Thanks.
> > >
> > > Thanks and Best Regards,
> > > Michael Sync
> > >
> > > Don't go the way life takes you.
> > > Take life the way you go
> > >
> > > http://michaelsync.net
> > >
> >
>

-- With Regards,
Kiran Badi
Email:kiran@...
Ph-India-(+91)9823378726
Ph-UK-(+44)2070239006
Ph- US-(+01)6178307605

This year's Agile 2011 conference (August 7 - 13, Salt Lake City)
will have a stage focusing on Embedded systems. James Grenning and I are
co-producing it, and submissions are open now.

    We are very interested in your experiences using Agile practices for
developing embedded products - large, small, in regulated environments,
beyond just software.... our stage description is here:

http://agile2011.agilealliance.org/program/stages/#Embedded


    I'll also take this opportunity to let you know that I am working on
a book on the same topic - how to apply Agile ideas and techniques to
embedded work. More news on that later!

   - Nancy V.


--
............................................
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

781 301 1822 US mobile
nancyv@...

http://www.leanagilepartners.com

Specialties: Agile coaching for Embedded Systems, for Data Migrations,
and for leadership of Lean-Agile change organization wide
............................................

It may be that I'm overreacting to your choice of words, but I get a bit worried
when you write things like "consequences for not succeeding in the
(retrospective) goals" and "they will get the butts kicked next time".

If you are changing your development process from a phased/waterfall type to
agile and at the same time introducing a new technology, a lot of people have to
relearn how to do parts of their work. To ease the "pain" of such a transition,
safety in the workplace is very important. Failure must be acceptable; a source
of information to be used for process improvement.

I get the impression that some of your management do not think this way.
Consider very carefully if you have sufficient management support at the right
level for the agile initiative. Also, try to gauge the level of managements
understanding of what makes scrum/agile work. If managers are still thinking
about individual developer performance benchmarks, it is a clear sign of the
need for coaching at a different level than development.

--- In scrumdevelopment@yahoogroups.com, "Brian" <bplawlor34@...> wrote:
>
> I think there's a combination of multiple incorrect practices which have been
going on...to be honest.
>    - Developers tackling too many Stories
>    - Focus on Functionality, not incorporating Visuals/Treatment
>    - Dev Team not Project focused
>    - Dev Team lacking required WPF coding experience
>
> The Retrospectives are active discussions, but they are repeating.  Everyone
recognizes the problems, but I guess we're still trying to improve our Iterative
practices.  Many of the discussions, which involved high bug counts which need
to be eliminated, repeated.  However, consequences for not succeeding in the
goals were never implemented, and that area is outside my control.
>
> Take multiple iterations of trying to scale back with quantity of Stories, but
seeing no improvements, plus a frustrated Exec Branch, and you get discussions
for a Story Quality Score to grade Dev performance.
>
> However, I think I have successfully talked them into a different path.  We're
going to take 1 Iteration and get caught up with all Bugs and lingering issues. 
The following Iteration, I'm creating a very transparent Bug Burn Down
Monitoring Chart.
>
> I've also worked hand-in-hand, walking the Dev Team through the Stories.  I'm
taking it a step further to facilitate proper Story production by only handing
over the specific Stories they will start with in the Iteration.  Once one is
noted as Done (a shipable product), I'll provide the next Story.  This should
eliminate working on too many at one time.  That will happen for the Iteration
after next, when they're back to Stories.
>
> The expertise of the Dev Team has improved and we have a couple more on the
way.  To be honest, I think we may be in good shape.  Proof is in the pudding of
course, but I believe I was able to keep the Exec's at bay one last time.  If
Dev Team doesn't follow what I've outline, they will get the butts kicked next
time.
>
>
> Thanks for everyone's feedback BTW.
> -Brian
>
> --- In scrumdevelopment@yahoogroups.com, "scrumnoob" <scrumnoob@> wrote:
> >
> > Hi Brian
> >
> > As has already been asked/stated, I to would be interested to know how this
conversation/issue played out at the retrospective(s).
> >
> > It is within the gift of the team to work out how to resolve whatever
quality issue there maybe, I would say it is their responsibility also.
> >
> > How has the issue manifest itself to execs if your defintion of done/done
includes all the levels of QA you mention?
> >
> > Best of luck
> >
> > Sean
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "Brian" <bplawlor34@> wrote:
> > >
> > > I guess I should elaborate a little bit more, however, I think you all
have expressed the concern I was looking for to utilize as ammo back up the
ladder.
> > >
> > > We have 4-week Iterations; which includes QA.  We do Unit and Buddy
testing, as well as all the regular QA, integration, regression testing.  We do
not have automated scripts yet, but will have in a month.
> > >
> > > It does sound like the Exec's will push for some sort of "Story Quality
Score".  I'm not sure I can stop that.  But, I may be able to sway them towards
focusing on the Story itself... avoiding individual grading.
> > >
> > > We'll see...
> > >
> > > Thanks to all of you for taking the time to lend your advice.  Our Company
has by migrating towards being more Agile after working in a Waterfall
environment for 30 years.  I guess we have some growing pains to work through
still.
> > >
> > > -Brian
> > >
> >
>

Agile 2011 – Insights- Experience Reports
http://agile2011.agilealliance.org/
August 7-13, 2011, Salt Lake City, USA

Insight reports share intriguing observations, hard fought wisdom, and
compelling stories about the nitty-gritty details of agile tactics,
practices, values, and challenges. This stage amplifies the voices and
experiences of those who don’t typically present at conferences. We are
also interested in hearing from those who’ve previously shared
experiences and want to update their progress.

If your insight proposal is accepted, we will work with you
(shepherding) as you write a 6-8 page paper that will be published in
the conference proceedings. Presenters on the insight stage also commit
to preparing a half-hour presentation as well as writing a paper about
their experiences.

In your proposal, include a brief description presenting your background
and experience (entered into the submission system as text) and 1-2
pages with a few more details and key insights. Also include information
on how we can contact you. We may want to chat with you during our
review process to ask you specific questions.

Your final report should read like an investigative report, explaining
what happened, why it happened, who it happened to, and why we should care.
We are interested in proposals exploring these and other provocative
questions:

- How did you uniquely scale, blend, adapt or evolve agile practices?
- What mistakes did you make? What insights have you gained that others
need to know about?
- What was it like integrating agile development into to the rest of
your organization?
- How successful were you in overcoming challenges? What challenges remain?
- If you’ve been doing agile development for some time, how have your
values or ways of working changed? What are you doing now and why?
- How have you uniquely addressed architecture, design, usability,
quality assurance, hardware, deployment, marketing, product definition,
or regulatory constraints?

Important dates:

- Last day to submit proposal: February 14
- Notification of all shepherding assignments: February 21
- Shepherding begins: February 22 (some shepherding might start earlier)
- Notification of rejected proposals: March 1
- Final Insight paper due to shepherd: April 1
- Final notification of acceptance: April 18
- Camera-ready report due: May 1
- Presentations: week of August 7

Submission Process:

Initial proposals will be reviewed by at least 3 members of the insights
review committee. Proposals will be reviewed as they are received. It is
better to get your proposal in early as we then will have time to review
it more thoroughly. Proposals that pass an initial review will be
assigned a shepherd from the committee. The proposer will then be
shepherded in writing a 6-8 page paper. If your paper is recommended for
acceptance by the shepherd and then accepted by the committee it will be
published in the electronic proceedings. Final papers must follow the
IEEE Proceedings format
(http://www.computer.org/portal/web/cscps/formatting).

Upon notification of acceptance, authors will be asked to complete a
copyright form and will receive further instructions for preparing their
camera ready version. At least one author of each insight report is
expected to register for the conference and present the results at Agile
2011.

Best paper award: The IEEE Software Agile 2011 Best insight paper award
will be given to the paper deemed by the review committee to be the most
engaging, reflective, and interesting experience report.

Organization:

Insights Stage Co-Producers: 
Rebecca Wirfs-Brock, Wirfs-Brock
Associates, and Linda Rising, Independent consultant

Review Committee:

Brian Foote, Independent consultant
Eric Willeke, Rally Software Development
Ian Savage, McAfee
Johanna Rothman, Rothman Consulting Group
Joseph Yoder, The Refactory
Nanette Brown, SEI
Rob Myers, Agile Institute
Rhea Staddick, Intel
Tim O’Conner, K12

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.

AJ

Hi Jedi,

> For example, I have seen using generics banned because the majority
> of the developers did not understand how to read the syntax.


What in the world has that got to do with swarming? This is not the
argument you are looking for.

Parallelizing work too much often kills a team's velocity. Encouraging
a team to "swarm" sets up a countervailing force.

Does your team often get to the end of an iteration with more than one
story unfinished? Then they will probably benefit from swarming. That
simple.

Cheers,
Laurent Bossavit
laurent@...

--- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
>
> Does your team often get to the end of an iteration with more than one
> story unfinished? Then they will probably benefit from swarming. That
> simple.

Is this the general way to address unfinished stories?

Hi Jedi,
> Is [swarming] the general way to address unfinished stories?
>


It's one way.

What else would you consider if the team often ends up with two or
more unfinished stories at the finish line?

Cheers,
Laurent Bossavit
laurent@...

 

--- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
>
> Does your team often get to the end of an iteration with more than one
> story unfinished? Then they will probably benefit from swarming. That
> simple.

Is this the general way to address unfinished stories?

Hello, agilejedi.  On Monday, January 3, 2011, at 4:21:40 PM, you
wrote:

>> Does your team often get to the end of an iteration with more than one
>> story unfinished? Then they will probably benefit from swarming. That
>> simple.

> So this is the new approach to address the issue of splitting up
> tasks smaller and smaller? Now we don't have to split it up and do
> the effort of splitting it up as if an individual were to work on
> it. We just size it at a higher level and then the team split it
> up when the get to it? So less planning?

This reply suggests to me that you're not really interested in being
convinced about swarming. Is that the case?

Ron Jeffries
www.XProgramming.com
Accept your conditions, but not your fate.  -- Rod Walsh & Dan Carrison

Hi Jedi,
> > Parallelizing work too much often kills a team's velocity.
> Really? Or is it that tasks aren't broken down and sized to fit
> iterations because everyone is working in their queue and have lost
> interest in some time box?
>

In one particular case I've seen this happen, the stories were broken
down into tasks that seemed adequately sized.

What would happen, though, was something you could easily spot as a
dynamic pattern on the task board:

s1 XXXX | |
s2 YYYY | |
s3 ZZZZ | |

at the start (given the usual three columns, lines represent three
stories broken down into letter tasks), then

s1 XXX | X |
s2 YYY | Y |
s3 ZZZ | Z |

a few days later, as people started more than one story
simultaneously. By the end of the iteration you'd see

s1 | X  | XXX
s2 | Y  | YYY
s3 | ZZ | ZZ

and not much of a velocity. My recommendation was to give swarming a
try - not as a rigid rule, more as turning a dial in the direction of
putting more emphasis on getting stories done. The idea was to see
this instead by iteration's end:

s1      | | XXXX
s2      | | YYYY
s3 ZZZZ | |

Same number of tasks done, two more stories done.

> So this is the new approach to address the issue of splitting up
> tasks smaller and smaller? Now we don't have to split it up and do
> the effort of splitting it up as if an individual were to work on
> it. We just size it at a higher level and then the team split it up
> when the get to it? So less planning?
>

It's not so much a matter of splitting things up explicitly or not, or
when you split them up, or how big or small. As I see it, anyway. (You
make it sound as if my opinion is somehow representative of large
numbers of people's. Flattering, but unlikely.)

It's more a matter of preferring to get things finished over getting
things started. And it's a dial, not a binary thing.

Cheers,
Laurent Bossavit
laurent@...

Hello, agilejedi.  On Monday, January 3, 2011, at 4:40:57 PM, you
wrote:

>> Does your team often get to the end of an iteration with more than one
>> story unfinished? Then they will probably benefit from swarming. That
>> simple.

> Is this the general way to address unfinished stories?

If you get to the end of an iteration with more than one unfinished
story, that tells us that people were working on the most important
of those stories ... and on the least important. It makes us think
that a little more focus on the most important one might have gotten
it done.

Ron Jeffries
www.XProgramming.com
I must create a system, or be enslaved by another man's;
I will not reason and compare; my business is to create. --William Blake

>
> Hi Jedi,
> > Is [swarming] the general way to address unfinished stories?
> >
>
>
> It's one way.
>
> What else would you consider if the team often ends up with two or
> more unfinished stories at the finish line?
>

If people are sitting around and done with their stories then they could ask if
their assistance would help.

If everyone is working the story goes unfinished.

If this is a constant problem of unfinished stories then:
1) Are individuals starting one story and finishing it before starting another
(Manage Work In Progress)
2) Does the team work best with stories that are bigger, if so, increase the
iteration length.
3) Don't worry about it, work was done, work is being done, and the work will be
continued until it is finished, so stop sweating it.

Just some quick thoughts.

--- In scrumdevelopment@yahoogroups.com, Jussi Mononen <agilepoodle@...> wrote:
> Hi AJ,
>
> to me your outburst sounds, well, overcomplicated.

It is overcomplicated, but really it is ill defined. Swarming was introduced to
me as an approach that is superior and shows maturity and that everyone works on
one story until it is done. Sounded wrong to me. Like there was no association
of the activity to a goal of delivering. Just showing off how well we can work
together. Who are we showing off to? I don't know.

Hello ronjeffries,

I am not interested in being convinced of swarming in the manner it has been
first introduced to me because it doesn't make sense. Therefore I am looking for
a better definition to see if that makes sense. Do you have one?

AJ

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, agilejedi.  On Monday, January 3, 2011, at 4:21:40 PM, you
> wrote:
>
> >> Does your team often get to the end of an iteration with more than one
> >> story unfinished? Then they will probably benefit from swarming. That
> >> simple.
>
> > So this is the new approach to address the issue of splitting up
> > tasks smaller and smaller? Now we don't have to split it up and do
> > the effort of splitting it up as if an individual were to work on
> > it. We just size it at a higher level and then the team split it
> > up when the get to it? So less planning?
>
> This reply suggests to me that you're not really interested in being
> convinced about swarming. Is that the case?
>
> Ron Jeffries
> www.XProgramming.com
> Accept your conditions, but not your fate.  -- Rod Walsh & Dan Carrison
>

laurent,

Excellent description.

Does having too many cooks in the kitchen come into play?
In my introduction to swarming it seemed that all we were going to do is bog
down the expert and ultimately the owner of the code set with the burden of
coordinating all of our help.

Of course the answer is "It depends". But swarming was pitched as the only
mature and reasonable approach.

AJ

On Mon, Jan 3, 2011 at 1:40 PM, agilejedi <agilejedi@...> wrote:
>
>
>
> --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@...> wrote:
> >
> > Does your team often get to the end of an iteration with more than one
> > story unfinished? Then they will probably benefit from swarming. That
> > simple.
>
> Is this the general way to address unfinished stories?
>

No. The purpose of swarming is not to address unfinished stories. The
purpose of swarming is to increase quality and consistency by getting
the whole team involved in a story as near to the beginning as
possible.

If you increase quality and consistency then as a side effect you
learn how much you can do in a small increment of time. You can use
that knowledge to estimate what you can get done over time and never
take on more than you are reasonably confident you can finish.

The reason that quality and consistency are higher with swarming than
with parallel work is that all of the skills and abilities of the
entire team (including the customer) are brought to bear on a single
item maximizing its chance for success. Of course, this only works for
small teams that have learned to work well together, but for such
teams it works extraordinarily well.

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, agilejedi.  On Monday, January 3, 2011, at 4:40:57 PM, you
> wrote:
>
> >> Does your team often get to the end of an iteration with more than one
> >> story unfinished? Then they will probably benefit from swarming. That
> >> simple.
>
> > Is this the general way to address unfinished stories?
>
> If you get to the end of an iteration with more than one unfinished
> story, that tells us that people were working on the most important
> of those stories ... and on the least important. It makes us think
> that a little more focus on the most important one might have gotten
> it done.
>

Okay, that makes perfect sense.

This code is released seldom, so the idea of one story being exceptionally more
important than another during an iteration only comes into play if that story is
a base for building other stories and therefore someone might be waiting. As the
stories build up to a certain amount of improvements and new features then the
application is delivered. The code is well divided along lines of expertise and
usually no one waits on another. Scrum is "strongly" encouraged and maybe it
doesn't fit, so therefore my confusion with swarming in general. Our world is
different, and maybe simpler than most. We might be the lucky ones.

--- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
>
> On Mon, Jan 3, 2011 at 1:40 PM, agilejedi <agilejedi@...> wrote:
> >
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@> wrote:
> > >
> > > Does your team often get to the end of an iteration with more than one
> > > story unfinished? Then they will probably benefit from swarming. That
> > > simple.
> >
> > Is this the general way to address unfinished stories?
> >
>
> No. The purpose of swarming is not to address unfinished stories. The
> purpose of swarming is to increase quality and consistency by getting
> the whole team involved in a story as near to the beginning as
> possible.

That doesn't seem to be the same as other explanations. Not that the desire to
increase quality isn't good. Increased consistency may not be a concern for me.

>
> If you increase quality and consistency then as a side effect you
> learn how much you can do in a small increment of time. You can use
> that knowledge to estimate what you can get done over time and never
> take on more than you are reasonably confident you can finish.
>
> The reason that quality and consistency are higher with swarming than
> with parallel work is that all of the skills and abilities of the
> entire team (including the customer) are brought to bear on a single
> item maximizing its chance for success. Of course, this only works for
> small teams that have learned to work well together, but for such
> teams it works extraordinarily well.
>

To me it was a confusion. I worked on some trivial aspect of the story and I had
to constantly check in code and get new code and tell my team mates what I was
doing because we were all in the same area, files, and classes. One of us could
have easily done it all, with out any over head.

I found it enjoyable though, but not efficient. It was nice sitting around
chatting and making a lot of ruffling sounds and working together. It wasn't
efficient.

Is there risk because one person does it. Sure, but not as much as people seem
to make it. That is very little new under the sun, I can figure out anyone's
code on the team and they can figure mine out. An inexperienced programmer can
figure no one's out.

Mary Doria Russell said "Wisdom begins when we learn the difference between
'That makes no sense', and 'I don't understand'."

Be that as it may, if your organization really doesn't want to ship very often,
and you're happy with important things being in the sole hands of "experts", 
and so on, maybe you don't need any different approaches. I do wonder why you
call yourself "Agile Jedi", but I suppose I could call myself Suzie if I wanted
to.

Why does your organization "highly recommend" Scrum? Is there something that
they want that they aren't getting now? How do you propose to get it without
doing new things?

R

On Jan 3, 2011, at 9:28 PM, "agilejedi" <agilejedi@...> wrote:

> Hello ronjeffries,
>
> I am not interested in being convinced of swarming in the manner it has been
first introduced to me because it doesn't make sense. Therefore I am looking for
a better definition to see if that makes sense. Do you have one?
>
> AJ
>
> --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>>
>> Hello, agilejedi.  On Monday, January 3, 2011, at 4:21:40 PM, you
>> wrote:
>>
>>>> Does your team often get to the end of an iteration with more than one
>>>> story unfinished? Then they will probably benefit from swarming. That
>>>> simple.
>>
>>> So this is the new approach to address the issue of splitting up
>>> tasks smaller and smaller? Now we don't have to split it up and do
>>> the effort of splitting it up as if an individual were to work on
>>> it. We just size it at a higher level and then the team split it
>>> up when the get to it? So less planning?
>>
>> This reply suggests to me that you're not really interested in being
>> convinced about swarming. Is that the case?
>>
>> Ron Jeffries
>> www.XProgramming.com
>> Accept your conditions, but not your fate.  -- Rod Walsh & Dan Carrison
>>
>
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...! Groups Links
>
>
>

On Mon, Jan 3, 2011 at 6:50 PM, agilejedi <agilejedi@...> wrote:
>
>
>
> --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
>
> >
> > On Mon, Jan 3, 2011 at 1:40 PM, agilejedi <agilejedi@...> wrote:
> > >
> > >
> > >
> > > --- In scrumdevelopment@yahoogroups.com, Laurent Bossavit <laurent@>
wrote:
> > > >
> > > > Does your team often get to the end of an iteration with more than one
> > > > story unfinished? Then they will probably benefit from swarming. That
> > > > simple.
> > >
> > > Is this the general way to address unfinished stories?
> > >
> >
> > No. The purpose of swarming is not to address unfinished stories. The
> > purpose of swarming is to increase quality and consistency by getting
> > the whole team involved in a story as near to the beginning as
> > possible.
>
> That doesn't seem to be the same as other explanations. Not that the desire to
increase quality isn't good. Increased consistency may not be a concern for me.
>

I don't disagree with any specific thing Ron or Laurent said, but I do
think finishing stories by the end of the Sprint is a side effect and
getting stories done with consistently high quality is the goal. In
the end Sprints are arbitrary time boxes, and unless the end of Sprint
date happens to correspond to some meaningful business event it is an
arbitrary date too.

There are a number of reasons why it is important to take on less at a
time in order to ensure quality and consistency. These can be boiled
down to the mathematics of uncertainty and queues, but it is not
necessarily to understand this in detail to take advantage of it for
your team. In the end it is a risk management strategy and it is about
making sure that a reasonable number of items are highly successful
and the defect rate is as near to zero as possible.

> >
> > If you increase quality and consistency then as a side effect you
> > learn how much you can do in a small increment of time. You can use
> > that knowledge to estimate what you can get done over time and never
> > take on more than you are reasonably confident you can finish.
> >
> > The reason that quality and consistency are higher with swarming than
> > with parallel work is that all of the skills and abilities of the
> > entire team (including the customer) are brought to bear on a single
> > item maximizing its chance for success. Of course, this only works for
> > small teams that have learned to work well together, but for such
> > teams it works extraordinarily well.
> >
>
> To me it was a confusion. I worked on some trivial aspect of the story and I
had to constantly check in code and get new code and tell my team mates what I
was doing because we were all in the same area, files, and classes. One of us
could have easily done it all, with out any over head.
>

However, if one of you got it done alone no one else would know how
they did it. There might be advantages to knowing how your teammate
does something. There might be something you could contribute that she
didn't thing of.

You could view those coordination costs as overhead, and they do add
up (That's the reason this only really works for small teams.) Still,
some of us have been doing it for a while and found the benefits to
outweigh the costs. I am not aware of any better way to get everyone
on the team to know what is going on and how to contribute. I am not
aware of any better way to develop the total flexibility to change
directions as needed. If you and your business value these things it
is worth learning, but maybe that is not the case for you.

> I found it enjoyable though, but not efficient. It was nice sitting around
chatting and making a lot of ruffling sounds and working together. It wasn't
efficient.
>

There is a difference between being busy and being efficient. I am
willing to bet that what you perceive as efficiency is really whether
you think you are busy or not (And you extrapolate from that that the
rest of your team is just as busy as you are.) The only way to prove
it would be to measure the throughput both ways and find out.

> Is there risk because one person does it. Sure, but not as much as people seem
to make it. That is very little new under the sun, I can figure out anyone's
code on the team and they can figure mine out. An inexperienced programmer can
figure no one's out.
>

Agreed, and in the environment that you are in it may be that the
benefits don't outweigh the risks. Maybe you don't actually need to
know how the entire system works right now. Maybe it is good enough
that you could find out at some point if you needed to.