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

Can you call it agile with a long distance team mate?

Expand Messages
  • Brian Beaudet
    We ve got a core group of 3 developers on our product with some additonal help from our team leader (when he s available). We have been Scrumming for about 4
    Message 1 of 5 , Jun 30, 2006
      We've got a core group of 3 developers on our product with some additonal help from our team leader (when he's available).  We have been Scrumming for about 4 or 5 sprints - none of which have ended on time.  Part of the problem, I believe, is that one of us is in GA while the other two share office space in NC.  We have our daily scrum on our conference line and very rarely actually stand up.
       
      To top it off, all of us can get called off of working on iteration items to address "fires" coming from installers out in the field.  These can be quick fixes or time intensive depending, obviously, on the nature of the problem. 
       
      I'm off to attend Scrum Master training in a few weeks so I can better put to use what I've learned from a few books and online blogs/articles. 
       
      However, given the structure of our team, do you think we even have a chance at making this work - in a Scrum paradigm?  I'm the offical company Scrum cheerleader and I really like what I've seen.  Before I got there, I had no clue what to work on and when.  Now, we've got that somewhat under control, for the most part.
       
      The other two team members aren't as in to it as I am but we have a mandate from up above that says do it, so they follow along half heartedly.
       
      That's the basics.  What do you think?
       
      Brian
    • Tobias Mayer
      Hi Brian, Having Scrum mandated is certainly about the worst starting point. Nevertheless, given that one of the team (i.e. you) clearly has a desire to see
      Message 2 of 5 , Jun 30, 2006
        Hi Brian,
         
        Having Scrum mandated is certainly about the worst starting point.  Nevertheless, given that one of the team (i.e. you) clearly has a desire to see this work there are steps you can take to improve the situation.
         
        You mention three developers, but don't say anything about testers, or UX's, or business analysts, or...  Scrum requires a full cross-functional team of all persons/skills needed to deliver working software at the end of an iteration.  That may be the first thing to address.  Where are the other necessary people located?  Can you discuss with them the possibility of closer collaboration with the developers?  A team of three deveopers is not a Scrum team, but it is a step towards one.   Learn more about self-organizing, cross-functional teams and take the next steps to creating such a team.
         
        In terms of the fires/escalations, the best thing you can do is start to track what percentage of your time is spent on these - begin with the current sprint - and then commit to correspondingly less on your next sprint.  Commit to less and less each sprint until you finally deliver what you committed to.  This will act as a guide, as a baseline.  Wherever possible, persuade your manager/s to prioritize the escalations and have them wait for the next sprint.  I worked with one team that quickly found that their escalation level was at 60%; this made comitting to anything very difficult, but it was good knowledge (with hard evidence in the way of task cards with big red "X"s on them) to pass on to the management team as an impediment to progress.
         
        Keeping sprints short (e.g. 2 weeks, or even 1 week) is a good way to get into the rhythm of Scrum, and will also help ensure that escalations can be deferred to the next sprint: customers who won't wait 4-8 weeks may be willing to wait 1-4 weeks.
         
        Distributed teams are not ideal for Scrum, but they can work when the desire is there.  The lack of enthusiasm from your co-workers is probably the biggest problem.  Have they had any Agile training?  I'd advise that you invite them to join you on the CSM course, or that they attend an Agile Team Training course; they should at least be more aware of what this Agile thing is that they don't want to do. 
         
        Scrum is a simple framework, with few requirements.  In fact you could condense it down to three: desire to learn, willingnesss to change, and an existing process that is completely broken.  Trouble is, many people lose the desire to learn as their jobs become more secure, most people are very resistant to change - in any circumstance, and almost no one in charge of processs is willing to admit that their process is broken, or even slightly flawed.  So clearly implementing Scrum in an organization is not simple at all, but very, very tough.  However, the problems you mention here are all common ones, and people on this list (and beyond) have successfully solved many of them, so there is hope.  Good luck - and keep seeking.
         
        Regards,
        Tobias Mayer
         
         

        Brian Beaudet <bbeaudet@...> wrote:
        We've got a core group of 3 developers on our product with some additonal help from our team leader (when he's available).  We have been Scrumming for about 4 or 5 sprints - none of which have ended on time.  Part of the problem, I believe, is that one of us is in GA while the other two share office space in NC.  We have our daily scrum on our conference line and very rarely actually stand up.
         
        To top it off, all of us can get called off of working on iteration items to address "fires" coming from installers out in the field.  These can be quick fixes or time intensive depending, obviously, on the nature of the problem. 
         
        I'm off to attend Scrum Master training in a few weeks so I can better put to use what I've learned from a few books and online blogs/articles. 
         
        However, given the structure of our team, do you think we even have a chance at making this work - in a Scrum paradigm?  I'm the offical company Scrum cheerleader and I really like what I've seen.  Before I got there, I had no clue what to work on and when.  Now, we've got that somewhat under control, for the most part.
         
        The other two team members aren't as in to it as I am but we have a mandate from up above that says do it, so they follow along half heartedly.
         
        That's the basics.  What do you think?
         
        Brian

      • wieberneitt
        Hi Brian, agile (not only scrum) also works in a distributed environment, although it obviously is not the optimal way e.g. in terms of communication. To me it
        Message 3 of 5 , Jul 3, 2006
          Hi Brian,

          agile (not only scrum) also works in a distributed environment,
          although it obviously is not the optimal way e.g. in terms of
          communication. To me it appears that you have 3 problems:

          1. your team members cannot concentrate on their development topics
          but have unplannable tasks. For this you likely need to have a good
          estimation in order to be able to come to a capacity that you can work
          with.

          2. You talk of developers only. There should be some more
          capabilities, starting from some product management (product owner),
          going via analysts to testing personnel. Or do your developers do all
          these tasks?

          3. The commitment level in your team. Here you clearly need to do
          something; probably a training or evangelizing the benefits.

          Best regards
          Thomas


          --- In scrumdevelopment@yahoogroups.com, "Brian Beaudet"
          <bbeaudet@...> wrote:
          >
          > We've got a core group of 3 developers on our product with some
          additonal help from our team leader (when he's available). We have
          been Scrumming for about 4 or 5 sprints - none of which have ended on
          time. Part of the problem, I believe, is that one of us is in GA
          while the other two share office space in NC. We have our daily scrum
          on our conference line and very rarely actually stand up.
          >
          > To top it off, all of us can get called off of working on iteration
          items to address "fires" coming from installers out in the field.
          These can be quick fixes or time intensive depending, obviously, on
          the nature of the problem.
          >
          > I'm off to attend Scrum Master training in a few weeks so I can
          better put to use what I've learned from a few books and online
          blogs/articles.
          >
          > However, given the structure of our team, do you think we even have
          a chance at making this work - in a Scrum paradigm? I'm the offical
          company Scrum cheerleader and I really like what I've seen. Before I
          got there, I had no clue what to work on and when. Now, we've got
          that somewhat under control, for the most part.
          >
          > The other two team members aren't as in to it as I am but we have a
          mandate from up above that says do it, so they follow along half
          heartedly.
          >
          > That's the basics. What do you think?
          >
          > Brian
          >
        • Ronica Roth
          ... Regarding the communication among a distributed team, the keys are commitment and creativity. Commitment means making a point of reaching out to one
          Message 4 of 5 , Jul 7, 2006
            > --- In scrumdevelopment@yahoogroups.com, "Brian Beaudet"
            >
            > <bbeaudet@...> wrote:
            > >
            > > We've got a core group of 3 developers on our product with some
            > additonal help from our team leader (when he's available). We have
            > been Scrumming for about 4 or 5 sprints - none of which have ended on
            > time. Part of the problem, I believe, is that one of us is in GA
            > while the other two share office space in NC. We have our daily scrum
            > on our conference line and very rarely actually stand up.
            > >


            Regarding the communication among a distributed team, the keys are
            commitment and creativity.

            Commitment means making a point of reaching out to one another--to ask
            questions, send updates, confer on design/solutions, etc. It means
            making that concious decision, when a question comes up, to initiate
            contact rather than just wait til the daily or plow on without
            conversation.

            Creativity means making it work. Figure out what's hard about
            communicating and focus on solutions. I am a remote product owner. One
            problem was that the developers and I were always afraid of
            interrupting concentration with phone calls. So we use IM a lot. Feels
            like a "distraction" the recipient can control better. Also, IM allows
            easy creation of 'chats' in which multiple team members can
            participate. I heard of one team that kept an open chat window during
            certain hours of the day, to encourage collaboration. Another team I
            read about had a conference phone line open during certain hours of
            the day.

            I also make a point--at the end of every daily meeting--of letting the
            team know about my availability, the best ways to reach me throughout
            the day. Or just reminding them to call anytime with questions.

            GoToMeeting is also my friend. A picture is worth 1,000 words.

            Finally, get creative about how you track sprint commitments and
            progress. Wikis, spreadsheets, etc all provide fine distributed
            versions of index cards and white boards.

            Good luck!

            Ronica
          • Andy Kriebel
            I would suggest you read Chapter 3 (Communicating, Cooperating Teams) of Agile Software Development by Alistair Cockburn. There are many tips and tricks
            Message 5 of 5 , Jul 7, 2006
              I would suggest you read Chapter 3 (Communicating, Cooperating Teams)
              of Agile Software Development by Alistair Cockburn. There are many
              tips and tricks listed.

              Andy

              --- In scrumdevelopment@yahoogroups.com, "Ronica Roth"
              <ronicaroth@...> wrote:
              >
              > > --- In scrumdevelopment@yahoogroups.com, "Brian Beaudet"
              > >
              > > <bbeaudet@> wrote:
              > > >
              > > > We've got a core group of 3 developers on our product with some
              > > additonal help from our team leader (when he's available). We have
              > > been Scrumming for about 4 or 5 sprints - none of which have ended on
              > > time. Part of the problem, I believe, is that one of us is in GA
              > > while the other two share office space in NC. We have our daily scrum
              > > on our conference line and very rarely actually stand up.
              > > >
              >
              >
              > Regarding the communication among a distributed team, the keys are
              > commitment and creativity.
              >
              > Commitment means making a point of reaching out to one another--to ask
              > questions, send updates, confer on design/solutions, etc. It means
              > making that concious decision, when a question comes up, to initiate
              > contact rather than just wait til the daily or plow on without
              > conversation.
              >
              > Creativity means making it work. Figure out what's hard about
              > communicating and focus on solutions. I am a remote product owner. One
              > problem was that the developers and I were always afraid of
              > interrupting concentration with phone calls. So we use IM a lot. Feels
              > like a "distraction" the recipient can control better. Also, IM allows
              > easy creation of 'chats' in which multiple team members can
              > participate. I heard of one team that kept an open chat window during
              > certain hours of the day, to encourage collaboration. Another team I
              > read about had a conference phone line open during certain hours of
              > the day.
              >
              > I also make a point--at the end of every daily meeting--of letting the
              > team know about my availability, the best ways to reach me throughout
              > the day. Or just reminding them to call anytime with questions.
              >
              > GoToMeeting is also my friend. A picture is worth 1,000 words.
              >
              > Finally, get creative about how you track sprint commitments and
              > progress. Wikis, spreadsheets, etc all provide fine distributed
              > versions of index cards and white boards.
              >
              > Good luck!
              >
              > Ronica
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.