Agile Programming and Teleworking
Tim Sharrock
occasional poster from the early days of the group (yes google
groups finds two posts from 1997/1998) let us try an on-topic
posting to see if there is enough interest to keep the group
alive (I am currently undecided)
I have been programming, almost entirely from home, for the same
employer for most of the last fifteen years. My current management
are changing their approach to a much more agile style. This is not, as far
as I can tell, following a single methodology but involves very fast
context switches to address the currently perceived top risks - the team
leads get together decide/are told what the current top risks are and grab
a few available developers to investigate/address them until they are no
longer the top-priority.
I am looking for experiences and evidence as to whether or not this
style of working can accommodate a remote worker - it is obviously harder,
as there is a something of a communication barrier caused by lack of
overheard conversations and lunchtime chats.
The best discussion of this sort of issue that I have found is
"Agile Development and Remote Teams: Learning to Love the Phone"
by Christian Sepulveda
http://www.agiledevelopmentconference.com/2003/files/R12Paper.pdf
Most of the other links that I have found have been more to do with
off-shoring whole teams, rather than individuals off-site.
Does anyone have any success (or failure) stories to share in this
sort of environment?
Tim
--
Tim Sharrock (t...@sharrock.org.uk)
Chris Croughton
<tim-n...@sharrock.org.uk> wrote:
> I have been programming, almost entirely from home, for the same
> employer for most of the last fifteen years. My current management
> are changing their approach to a much more agile style. This is not, as far
> as I can tell, following a single methodology but involves very fast
> context switches to address the currently perceived top risks - the team
> leads get together decide/are told what the current top risks are and grab
> a few available developers to investigate/address them until they are no
> longer the top-priority.
Ugh. That's a sure way to burn out your developers really fast, as well
as ensuring that nothing ever gets finished (or even started) properly.
I take it they don't want the company to last much longer?
> I am looking for experiences and evidence as to whether or not this
> style of working can accommodate a remote worker - it is obviously harder,
> as there is a something of a communication barrier caused by lack of
> overheard conversations and lunchtime chats.
It's a bad management style period, and as you say it will hit remote
workers hardest because they aren't as "closely coupled" in the loop.
Even with Skype or other VoIP systems you can't pick up the casual
comments.
> The best discussion of this sort of issue that I have found is
> "Agile Development and Remote Teams: Learning to Love the Phone"
> by Christian Sepulveda
> http://www.agiledevelopmentconference.com/2003/files/R12Paper.pdf
I'll look at that when I have more time (and access to a PDF reader).
> Most of the other links that I have found have been more to do with
> off-shoring whole teams, rather than individuals off-site.
>
> Does anyone have any success (or failure) stories to share in this
> sort of environment?
My advice would be to look for another job. Or possibly shoot the
management, that's (a) usually a good idea on general principles but (b)
tends to get you locked away and so even more 'remote' <g>.
Seriously, I think it is a bery bad sign for all of the developers.
Well, OK, possibly a few like chopping and changing, but most will get
frustrated that they never really finish anything, it just becomes "not
as urgent", and the quality will drop drastically.
Chris C
Fabian
Tim Sharrock wrote:
> I have been programming, almost entirely from home, for the same
> employer for most of the last fifteen years. My current management
> are changing their approach to a much more agile style. This is not,
as far
> as I can tell, following a single methodology but involves very fast
> context switches to address the currently perceived top risks - the
team
> leads get together decide/are told what the current top risks are and
grab
> a few available developers to investigate/address them until they are
no
> longer the top-priority.
Hi Tim,
Sorry but I have not understood your point.
What are the supposed "top risks" they perceive? Or the mamagement is
looking for reasons for bringing telecommuters back in the office?
How do they investigate on the few grabbed developers? Interviews?
Surveys? Check on them?
"until they are no longer the top-priority". They what? The risks, the
developers, the investigation?
Cheers,
Fabian
Tim Sharrock
>On Fri, 29 Apr 2005 19:14:51 +Z, Tim Sharrock
> <tim-n...@sharrock.org.uk> wrote:
>
>> are changing their approach to a much more agile style [...] very fast
>> context switches to address the currently perceived top risks - the team
>> leads get together decide/are told what the current top risks are and grab
>> a few available developers to investigate/address them until they are no
>> longer the top-priority.
>
>Ugh. That's a sure way to burn out your developers really fast, as well
>as ensuring that nothing ever gets finished (or even started) properly.
It has not been universally popular with those I have spoken to (but
it has not yet been applied very much yet.
>I take it they don't want the company to last much longer?
well, it was founded as a research organisation whrn Tony Ben was Minister
of Technology... so we tend to think in terms of decades rather than months...
>> I am looking for experiences and evidence as to whether or not this
>> style of working can accommodate a remote worker - it is obviously harder,
>> as there is a something of a communication barrier caused by lack of
>> overheard conversations and lunchtime chats.
>
>It's a bad management style period, and as you say it will hit remote
>workers hardest because they aren't as "closely coupled" in the loop.
>Even with Skype or other VoIP systems you can't pick up the casual
>comments.
I would like to try true agile methods sometime. Management styles do
tend to oscillate somewhat between lack of control => overly rigid
process => lack of progress => excessive dynamism and randon activity.
I hope that one day a suitable balance will res-restablish.
>> Does anyone have any success (or failure) stories to share in this
>> sort of environment?
>
>My advice would be to look for another job.
I am keeping my eyes open, but not rushing, as in other ways the telecommuting
life-style is very convenient. (My wife has a higher-flying job than mine, so
having zero-commute on most days is very helpful for ferrying children
to school and picking them up from the after-school club - even a commute
into central Manchester on the tram would make fitting a full day inside
those time-limits hard.)
>Or possibly shoot the management, that's (a) usually a good idea on
> general principles but (b) tends to get you locked away and so even
> more 'remote' <g>.
!!!
>Seriously, I think it is a very bad sign for all of the developers.
>Well, OK, possibly a few like chopping and changing, but most will get
>frustrated that they never really finish anything, it just becomes "not
>as urgent", and the quality will drop drastically.
I tend to agree, I expect that the extreme version won't last long and
will milden down into something usable - the question is how long will
it take to do so...
Thanks for your thoughts
Tim Sharrock
>> are changing their approach to a much more agile style [...] very fast
>> context switches to address the currently perceived top risks - the team
>> leads get together decide/are told what the current top risks are and grab
>> a few available developers to investigate/address them until they are no
>> longer the top-priority.
>
>Ugh. That's a sure way to burn out your developers really fast, as well
>as ensuring that nothing ever gets finished (or even started) properly.
It has not been universally popular with those I have spoken to (but
it has not yet been applied very much yet.
>I take it they don't want the company to last much longer?
well, it was founded as a research organisation when Tony Benn was Minister
of Technology... so we tend to think in terms of decades rather than months...
>> I am looking for experiences and evidence as to whether or not this
>> style of working can accommodate a remote worker - it is obviously harder,
>> as there is a something of a communication barrier caused by lack of
>> overheard conversations and lunchtime chats.
>
>It's a bad management style period, and as you say it will hit remote
>workers hardest because they aren't as "closely coupled" in the loop.
>Even with Skype or other VoIP systems you can't pick up the casual
>comments.
I would like to try true agile methods sometime. Management styles do
tend to oscillate somewhat between lack of control => overly rigid
process => lack of progress => excessive dynamism and random activity.
I hope that one day a suitable balance will re-establish.
>> Does anyone have any success (or failure) stories to share in this
>> sort of environment?
>
>My advice would be to look for another job.
I am keeping my eyes open, but not rushing, as in other ways the telecommuting
life-style is very convenient. (My wife has a higher-flying job than mine, so
having zero-commute on most days is very helpful for ferrying children
to school and picking them up from the after-school club - even a commute
into central Manchester on the tram would make fitting a full day inside
those time-limits hard.)
>Or possibly shoot the management, that's (a) usually a good idea on
> general principles but (b) tends to get you locked away and so even
> more 'remote' <g>.
!!!
>Seriously, I think it is a very bad sign for all of the developers.
>Well, OK, possibly a few like chopping and changing, but most will get
>frustrated that they never really finish anything, it just becomes "not
>as urgent", and the quality will drop drastically.
I tend to agree, I expect that the extreme version won't last long and
will milden down into something usable - the question is how long will
it take to do so...
Thanks for your thoughts
Tim
--
Tim Sharrock (t...@sharrock.org.uk)
Tim Sharrock
>Tim Sharrock wrote:
>> I have been programming, almost entirely from home, for the same
>> employer for most of the last fifteen years. My current management
>> are changing their approach to a much more agile style. This is not,
>> as far as I can tell, following a single methodology but involves very
>> fast context switches to address the currently perceived top risks -
>> the team leads get together decide/are told what the current top risks
>
>Hi Tim,
>
>Sorry but I have not understood your point.
>
>What are the supposed "top risks" they perceive?
Things like (made up examples):
"will changing the database to add xxxx cause problems with
other modules of the system?"
"The fig-wibbling requirement is ambiguous and needs to be clarified
with respect to high-altitude operations"
"A bug has been reported in a bought-in component - does it affect our
use of it".
> Or the mamagement is looking for reasons for bringing telecommuters
> back in the office?
I am, as far as I know, the only programmer doing nearly complete1
telecommuting (there are others who are in an office most of the time,
but occasionally away)
>How do they investigate on the few grabbed developers? Interviews?
>Surveys? Check on them?
There are nearly always full-time employees of the company: part of a
"skills pool". This can lead to risks on project A "the developers
keep getting grabbed to project B which is a higher risk..."
>"until they are no longer the top-priority". They what? The risks, the
>developers, the investigation?
the risks, eg
"OK we understand the implications of xxxx now, the wombat-interface
will need to be extended to cope with it, and it will take about three
days to apply the changes. Fine, don't do it now, we can do it later,
I want you to look at fig-wibbling"
Sorry about the cryptic language!