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

3519Re: versus collocated teams

Expand Messages
  • Buck Calabro
    Jun 5, 2007
      Owen said:

      > I didn't see anything to either
      prove or
      > falsify any assertion made by anyone here.
      > I want to see proof the suitability of
      > collocation and remote work.

      > Either in an absolute sense, a statement that
      > can be backed by evidence

      I'm new to Agile too. Almost 30 years of mainframe, green screen, top down, waterfall, big database (multi-million row tables are commonplace.) My understanding of Agile is that it is a philosophy, not a rigid process, and as such, human factors are important. I'm prone to this understanding because with all my years, I've learnt that people write software, processes do not. The 'issue' with people is that there is no such thing as 'proof' - what works for you may be anathema to me, and vice versa. I do not believe we (humanity) will find provable truth in any human endeavour, only probabilities. Informed opinions are a guide to those probabilities, and not an absolute assertion that This Is The Only Way to go about the work. Each person must find what works for him. I value the advice of those who have gone before me, at least as a starting point. Heck, they've already made the beginner mistakes - if I can avoid them, my learning curve is that much shorter.

      > I bet that coding would be a

      > good candidate for remote work.

      Bringing the discussion a bit more toward my own goal for being here, I don't think that the Agile philosophy holds 'coding' as a separate activity from designing, thinking, planning, reviewing and testing. In my mainframe life, it's very common to have separate silos: one division does architecture, another detailed design, another coding and so on. Agile wants to bring these together (I think!) In my personal situation, I'll be doing a lot more than coding but I have worked in a traditional shop where 'coding' was outsourced to remote programmers, so I have some experience with that, the relating of which is more suitable to a traditional-usability list <smile>.

      I personally am just steeped in the silo scenario and want to break out. I'm reading everything I can in the hopes that I'll find a process that won't keep me process-bound! What a dichotomy...

      Best regards,
    • Show all 24 messages in this topic