- no argument... maybe my point was stupid... tools don t make the difference, people do. just like being in the same room doesn t make the difference, peopleMessage 1 of 341 , Feb 1, 2007View Sourceno argument... maybe my point was stupid...
tools don't make the difference, people do. just like being in the same
room doesn't make the difference, people do.
all i am trying to say (if i even remember my original brain fart) is
that a team all in the same room need not be (do not interpret as can't
or isn't) so formal about docs, doesn't need to do designs that make it
easier for separate teams to collaborate, and so on. and they can
succeed in splendid fashion. teams *not* in the same room cannot afford
these luxuries. they must (well, should) go to extra lengths to (over?)
communicate, over document, over design (typically to interfaces) for
splitting the work up and eliminating dependencies.
i guess it's too hard to describe without being in the same room.
mhpries said the following on 2/1/07 7:22 AM:
> --- In firstname.lastname@example.org
> <mailto:agile-usability%40yahoogroups.com>, Jon Kern <jonkern@...> wrote:
> > ... some simple examples...
> > when i worked with a team in St. Petersburg, RU, I would be onsite
> > weeks per month. i would have been more effective being onsite 100%
> > the time. (We were developing software products at TogetherSoft.)
> > However, being a distributed team meant i had to increase the level
> > which we ensured we always worked by being open, communicative, and
> > extra visible. so, we were more certain to have collaborative
> > to
> > collaborate -- ... this can lead
> > to a distributed team having to go further than a local team would
> > terms of building a collaborative workspace and artifacts. ...
> > ... we have been doing agile development with teams across 4
> > now... with success. sure, sometimes i wish we were together, but
> > and other techniques can help bridge the gap.
> I am curious about that. Specifically, what roles comprise your team?
> All you all developers? And where do the lead devs sit? And the
> analysts and testers, etc.
> I am curious because my experience has been more along the lines of
> Alain's. The best teams, for me, have happened when everybody was in
> the same room and the best configuration for those rooms were "war
> room" aka everyone facing each other around a big table; not
> cubicles. You don't even have to be in them 100% of the time but the
> central focus of each day should happen in a space where everyone
> comes together face to face.
> You can do all sorts of wonderful things with wikis, and webex, and
> video etc. but who's to make anybody pay attention if the spirit of
> the team is not unified?
> If the team players all have one role, then there is a bond that
> comes from doing the same type of work that overcomes distance but
> the more the roles vary - dev, analyst, QA, PM - the harder it is for
> the team to mesh if they are mostly separate.
> For example, once upon a time I was on a project where the starting
> PM had come from a rather formal, mostly waterfall consulting
> background and the devs were very into Agile methodologies but split
> between two countries with very little exchange (to start). The
> analysts (to start) spent about 75% of their time at the client, 20%
> working from home and about 5% in country A's team office with the PM
> (often in a war room with the PM but not the devs or IM). The PM
> focussed mainly on talking to the client, the analysts and the
> account mgr., and generally gave orders to the devs via the IM. The
> tension between the analysts and the devs (to start) was practically
> poisonous; ditto the IM and the PM; and the two dev teams had
> completely different philosophies.
> We had all the best practices Jon writes about but mainly they just
> served as tools for one side to bash the other. It wasn't until we
> got a new PM who began to treat the IM as a partner and who changed
> the analysts schedule, making them actually pair with devs, and who
> instilled some serious foreign exchange (weeks not days of visiting);
> that the team became a team.
> It's culture not tools that count; and culture (like yeast) grows
> best in close quarters.
- ... I just got back from another planet, it seems, so pardon me for asking dumb questions, but what *did* you expect? I myself do a lot of agile UX (note,Message 341 of 341 , Feb 23, 2007View SourceOn 2/23/07, Robert Hoekman, Jr. <rhoekmanjr@...> wrote:
> Without any hard feelings intended, the best thing I could do here is to simplyI just got back from another planet, it seems, so pardon me for asking
> stop engaging in this conversation. I'm sorry if this bothers you, but this list is
> simply not what I hoped it would be, and I believe I need to explore my
> interests elsewhere.
dumb questions, but what *did* you expect? I myself do a lot of agile
UX (note, small 'a'; there is no Agile) and I'm on this list, so I'm
curious about your "Great Wall of Agile on this list"; what is it?
Sure, a lot of people have *their* meaning of Agile and their way of
doing things, and as you say, that's ok. Do you feel some people
advocate only one way of Agile, perhaps a tad too much? That their
passion is getting in the way of pragmatism?
Project Wrangler, SOA, Information Alchymist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------