--- In email@example.com
, Ron Jeffries <ronjeffries@...>
> Hello, Owen. On Wednesday, May 30, 2007, at 11:55:22 PM, you
> > 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
> > 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?