Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Re: Remote versus collocated teams.

Expand Messages
  • Jon Kern
    re: It might be good to have a speaker phone handy which will allow members to lazily connect or contribute when the conversation drifts into topics that might
    Message 1 of 146 , Jun 3, 2007
    • 0 Attachment
      re: It might be good to have a speaker phone handy which will allow members
      to lazily connect or contribute when the conversation drifts into topics
      that might be of interest to various remote resources as would be
      dictated by the natural flow of the conversation. A stenographer would
      transcribe the conversation in real-time, and publish this conversation,
      or minutes thereof to, say, an IRC channel,

      Part of our "tool chest" is IRC.

      * All developers, QA, business folks, project managers are always
      online, tuned to our channel
      * We have a bot that is the "stenographer"
      * The IRC chats are recorded and available on our wiki
      * If you want someone's attention, ping their name and the IRC
      client makes a racket. That way people are only paying attention
      to IRC when they need to. Otherwise they are working away.

      I pasted just a small part of an IRC log from Friday afternoon (see
      below). Participants from:

      * Crete (heinz -- "the java specialist")
      * Eastern PA (me)
      * Georgia (andy)
      * Middle PA (ken and andrew)
      * California (mike and mark)
      * Middle New Jersey (marc, harry, QA)
      * missing: Denver and Iowa

      jon
      blog: http://technicaldebt.com

      *Example from IRC log that was accompanying a daily stand-up/scrum
      conference call. missing chunks of time are conversations on the telephone:*

      13:50 <jonkern> need to consider how to handle errors...
      13:51 <heinzmk> at least convert them to RuntimeExceptions
      13:51 <heinzmk> then we don't miss them
      13:52 <jonkern> Good idea andy! the issue is all yours :-)
      13:52 <ajpowell> fair enough
      13:53 <jonkern> mg-256
      13:54 <ajpowell> flex.messaging.messages.ErrorMessage
      13:54 <jonkern> and maybe an ErrorVO so we can translate to human
      readable and do messaging if needed...
      14:00 <jonkern> http://confluence. -blurredout-
      .com/display/MG/Feature+Overview
      14:06 <jonkern> mg-257 added for privs/roles mechanism
      14:06 <jonkern> mg-245 likely closed today
      14:06 <jonkern> perf scripts will be placed under svn
      14:07 <jonkern> heinz
      14:09 <heinzmk> if we make the delta management flexible, it would
      create a lot of SQL queries
      14:26 <jonkern>
      http://confluence.immuexa.com/display/MG/Quality+Assurance
      14:26 <jonkern> logging time in jira, keep the text small... maybe
      a sentence or two
      14:26 <heinzmk> and increments of 15m
      14:29 <jonkern> http://jira. -blurredout-
      .com/browse/MG-200?page=worklog
      14:30 <heinzmk> that is bad ...
      14:30 <heinzmk> :)
      14:30 <mmatrix> Sorry Mark, had to say it
      14:30 <ajpowell> this is an awfully long conversation on brevity :)
      14:30 <heinzmk> hehe
      14:31 <jonkern> :-)
      14:33 <heinzmk> for that we use the SVN logs
      14:34 <mmatrix> speaking of brevity, weren't Scrums supposed to be
      short? ;)
      14:34 <jonkern> yes!
      14:34 <heinzmk> bye
      14:34 <jonkern> thanks
      14:34 <jonkern> END-O-CHAT





      Owen Thomas said the following on 6/3/07 2:51 AM:
      >
      >
      >
      > Hello Ron.
      >
      > --- In agile-usability@yahoogroups.com
      > <mailto:agile-usability%40yahoogroups.com>, Ron Jeffries <ronjeffries@...>
      > wrote:
      > >
      > > Hello, Owen. On Wednesday, May 30, 2007, at 11:55:22 PM, you
      > > wrote:
      > >
      > > > I would assume that the programming I was asked to do was of
      > > > functionality that had been worked out at several higher levels, and
      > > > user documentation (if this is what you mean by asking me how my
      > work
      > > > gets documented) is being overseen by whomever I received the
      > > > programming work from.
      > >
      > > Normally on an Agile team, the system design, how the objects
      > > interact, and so on, is a team responsibility. As such, things like
      > > this are determined via a lot of discussion. So things aren't so
      > > much just handed out with some "higher level" god-like person doling
      > > out work to what I think you have called "code-cutters". Code cutter
      > > is not a job title in most Agile methods.
      >
      > Yes, I realise that, never having yet had the opportunity to be involved
      > in Agile development, my experience of of them is less than a bit
      > au-fait. I only have a very general knowledge of what is involved, but
      > continual customer involvement, and quick release cycles are two reasons
      > why Agile turned my head. I have worked in a more traditional Waterfall,
      > and can see the common sense in adopting these two earlier mentioned
      > approaches to handle changes in what is required while 'what is
      > required' is taking shape.
      >
      > > Normally on an Agile team, we recommend that the programmers choose
      > > their own work from the stories that the customer provides (or, less
      > > ideally IMO, from the technical tasks that the team has determined
      > > will implement the story). So again, as with the design, there isn't
      > > someone doling out work to the programmers. There is, instead,
      > > design discussion, task breakdown, and work selection.
      >
      > I see. While participating in this discussion, I have been coming to
      > terms with more of what's involved, and I see that instead of having
      > stuff pushed to team members so they can go away for a time and come
      > back to 'hand over' what is needed, each team member takes away whatever
      > they think their expertise and interests qualifies them to get involved
      > in. I would agree that this is a much looser way of teamwork. It sounds
      > like a good thing to do in a project for which the requirements are not
      > static, and again, I see this as having much value in a lot of what goes
      > on in agile projects.
      >
      > > When the team is all remote from each other, these discussions are
      > > difficult to have. I'm not sure how you'd come up with a coherent
      > > architecture and design in that situation, nor how you'd coordinate
      > > the task and work breakdown. What I see most often is a much more
      > > command and control approach, where work is handed much out as you
      > > contemplate. That is not what I'd call an Agile approach at all.
      >
      > I don't see why your assertion should have to be so. Admittedly, there
      > are tasks that have to get done that will require the collocated
      > participation of two or more team members, and they will naturally
      > collocate to undertake these tasks. However, it is still my belief that
      > much (usually most) of what goes on in a project can be done with equal
      > effect in a distributed environment. If I take a user story that
      > involves the creation of some type of application, algorithm, or
      > business process, I really don't see that so long as I have access to
      > the development code base and documentation I need, and the people I
      > need to talk to over IM, email, Skype, or phone, that I would
      > necessarily be at a disadvantage to other team members, so long as they
      > used these same methods to get the job done.
      >
      > I may agree that there are times (not for anything I would get involved
      > in) that for the pace of change, two of more resources might derive some
      > benefit from collocation. Such ideas, changing from one minute to the
      > next, would be in a most embryonic state, and one can forget about
      > writing a single line of code, or establishing a single process in
      > relation to them. Ideas of that immaturity are far too volatile to get
      > more than the prime stakeholders (possibly customer CEO's and the
      > project's lead consultants) involved.
      >
      > It might be good to have a speaker phone handy which will allow members
      > to lazily connect or contribute when the conversation drifts into topics
      > that might be of interest to various remote resources as would be
      > dictated by the natural flow of the conversation. A stenographer would
      > transcribe the conversation in real-time, and publish this conversation,
      > or minutes thereof to, say, an IRC channel, giving interested parties
      > the opportunity to contribute without having to remain connected to the
      > conference call. Additionally, the prime stake holders might want to
      > contact a remote resource to elicit advice when they have a question.
      >
      > As the customer is continually involved in the project, they would have
      > to be aware, and accepting of the communications channels that exist by
      > virtue of the geographically distributed nature of the project's
      > composition. I believe that the customer acceptance barrier, to me, may
      > be more difficult to surmount than convincing the members of this mail
      > group of the possibility that remote teaming is an Agile attribute that
      > gets the job done.
      >
      > Might this work? Might this not work?
      >
      > Owen.
      >
      >
    • kswaters1
      Here here Ron! Remote teamwork may be possible but it certainly isn t ideal. Close collaboration without co-location is a compromise, sometimes an essential
      Message 146 of 146 , Jul 11, 2007
      • 0 Attachment
        Here here Ron! Remote teamwork may be possible but it certainly
        isn't ideal. Close collaboration without co-location is a
        compromise, sometimes an essential one, but not one you'd advocate
        as part of any methodology.

        I sometimes like to think of this in terms of new business
        startups. How many people would start a business and think, "I
        know, let's base our development teams in multiple locations and
        have the business owners of the product we're building in a
        different place to the developers." For logistical reasons, sales
        and other field-based teams maybe, for product development I think
        not.

        Kelly Waters
        http://www.allaboutagile.com


        --- In agile-usability@yahoogroups.com, Ron Jeffries
        <ronjeffries@...> wrote:
        >
        > Hello, Owen. On Sunday, June 3, 2007, at 11:01:30 PM, you wrote:
        >
        > > I realise that many people aren't in my position such that they
        would
        > > want hard facts to decide. Many are going to trust the opinions
        of other
        > > people they may think have seasoned opinions, because they
        haven't got
        > > the time or the interest to decide for themselves. However, if
        John
        > > Kern's business, as a case in point, can demonstrate that the use
        > > communications tools to facilitate a remote team discussion is
        possible,
        > > then shouldn't the Agile community be a little less hard on
        remote
        > > teaming?
        >
        > Owen, even Jon said that together would be better. Why would we
        want
        > to recommend something that wasn't the best we know?
        >
        > Ron Jeffries
        > www.XProgramming.com
        > The fact that we know more today, and are more capable today,
        > is good news about today, not bad news about yesterday.
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.