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

Developers in 'Do Not Disturb' mode breaking the 'team' ?

Expand Messages
  • Jacob
    Hello everyone, In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using do not
    Message 1 of 23 , Feb 5, 2010
    • 0 Attachment
      Hello everyone,
       
      In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
       
      The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
       
      He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
       
      His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
       
      Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
       
      The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
       
      It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
       
      Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
       
      But how to achieve it...?
       
      Jacob
    • Alan Dayley
      Two heads are better than one. Only in exceptional circumstances is this not true. - The team should be working on stories, not individuals. - The team
      Message 2 of 23 , Feb 5, 2010
      • 0 Attachment
        "Two heads are better than one." Only in exceptional circumstances is
        this not true.

        - The team should be working on stories, not individuals.
        - The team should be writing code, not individuals.
        - No one should be doing lots of work that is only later crammed
        together with the work from others.
        - "Team work" does not mean doing a Daily Scrum once a day and then
        not talking to each other.
        - The stories should be written such that the require more than one
        person to complete them.
        - I suspect that this person is working on things that are defined to
        be isolated from other work.

        I understand what he is saying and the research backs him up. A
        creative person takes time to get "in the zone" and interruptions will
        disrupt that.

        Now, what if the interruptions were directly related to the work he is
        currently doing? Well, then the interruptions would be welcome! And
        what if two or more people, even the whole team were working on the
        same thing? Then interruptions would not be interruptions at all,
        they would be doing the work!

        Interruptions will happen. If the team swarms the stories and works
        them together, the interruptions are turned into productive time
        instead of disruption.

        And maybe the team should have a quiet day once a sprint or once a
        week. Because, sometimes, it is necessary to completely focus. :^)

        Alan

        On Fri, Feb 5, 2010 at 6:45 AM, Jacob <jacob@...> wrote:
        >
        >
        >
        > Hello everyone,
        >
        > In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
        >
        > The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
        >
        > He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
        >
        > His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
        >
        > Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
        >
        > The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
        >
        > It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
        >
        > Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
        >
        > But how to achieve it...?
        >
        > Jacob
        >
        >
      • Kurt Häusler
        Some people really need do need to work in isolation for extended periods like that. I don t think he is being too unreasonable in bringing it up at a
        Message 3 of 23 , Feb 5, 2010
        • 0 Attachment
          Some people really need do need to work in isolation for extended
          periods like that. I don't think he is being too unreasonable in
          bringing it up at a retrospective especially since he came prepared
          with a possible solution.

          It is also not unreasonable for the team to reject that solution.

          One possible idea is to give him tasks that require less collaboration
          with team members.

          If he is getting interrupted really every 15 minutes, even when the
          rest of the team know it hampers his work, then it could smell like
          the people doing the work are not the same people who have the
          information to do the work.

          It is less ideal to have team members that are more effective in
          isolation, but forcing collaboration rarely works, and it doesn't
          sound like you can ditch the guy so adapting and finding some
          compromise should work.

          Ideally you would be able to turn the situation into a positive, and
          find ways in which such a team member can actually contribute more in
          some way that more collaborative team members.

          He could also personally make some effort to realise that a certain
          amount of collaboration is required and work on being able to focus
          despite occasional interruption.

          Things could be worse, the main thing is you are discussing the issues
          at retrospectives and exploring various solutions. I would try and
          keep tempers and voices down though, it is only work after all.

          On Fri, Feb 5, 2010 at 2:45 PM, Jacob <jacob@...> wrote:
          >
          >
          >
          > Hello everyone,
          >
          > In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
          >
          > The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
          >
          > He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
          >
          > His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
          >
          > Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
          >
          > The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
          >
          > It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
          >
          > Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
          >
          > But how to achieve it...?
          >
          > Jacob
          >
        • Johanna Rothman
          Jacob, Take that guy off the team. He s not on the team anyway. Let him do what he wants on the side, not on this project. Team velocity is about *team* not
          Message 4 of 23 , Feb 5, 2010
          • 0 Attachment
            Jacob,

            Take that guy off the team. He's not on the team anyway. Let him do what he wants on the side, not on this project.

            Team velocity is about *team* not personal velocity. If the rest of the people need discussion, he needs to discuss with them, not work alone.

            *I* don't see how a person can be an adequate senior engineer, scrum master and partner in the company. He is making choices for himself. When he wants a day of me time, h's working as a senior engineer. If he was working as a scrum master, he would be paying attention to the obstacles, of which he is one. 

            People cannot multitask. He's telling you this with his cost-of-context-switch time. So, stop having him multitask. He needs to choose what he is going to do. 

            I would (gently, as nicely as I could) ask him to remove himself from the team. Or, if he wants to contribute technically, learn how to work as part of a team, not as the top guy on the hierarchy.

            Johanna

            On Feb 5, 2010, at 8:45 AM, Jacob wrote:

             

            Hello everyone,
             
            In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
             
            The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
             
            He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
             
            His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
             
            Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
             
            The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
             
            It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
             
            Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
             
            But how to achieve it...?
             
            Jacob


            --

            Rothman Consulting Group, Inc.     781-641-4046

            Speaker, Author, Consultant - Managing Product Development

            ==========================================

            The Pragmatic Manager newsletter: http://www.jrothman.com/pragmaticmanager

            http://www.ayeconference.com, Nov 7-11, 2010

            New: Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects




          • Peter Stevens (calendar)
            Hi Jacob, The ScrumMaster and Partner is doing this? Wow. Incredible Scrum-But! I started to write the following answer, then I realized the role the ... How
            Message 5 of 23 , Feb 5, 2010
            • 0 Attachment
              Hi Jacob,

              The ScrumMaster and Partner is doing this? Wow. Incredible Scrum-But!

              I started to write the following answer, then I realized the role the person has in the company, so I am not sure it will work in this case:
              >>>
              How to find a compromise?  Start by asking "why?" and listen to the answer. Encourage everyone else to listen, don't allow criticisms, justifications or rebuttals, just let everyone say why they need what they need. How is the S-M's moderation technique in the retrospective?

              You might want to take a look at the Pomodoro technique. 25 Minutes of DND followed by 5 min of break, with a longer break every 3 'tomatoes' or so. During the break, the developer is interruptible.

              Let him protect himself, but give interrupt points where the team can talk to him...
              >>>

              Not knowing how big the company is, or what your role is, it is hard to say if that will work or if you can do it. Maybe you need another Partner or the P-O to mediate. An external coach might be useful as well. 'Let's do a Scrum Assessment and see how we're doing'.

              Good luck!

              Peter

              On 05.02.10 14:45, Jacob wrote:  
              Hello everyone,
               
              In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
               
              The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
               
              He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
               
              His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
               
              Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
               
              The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
               
              It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
               
              Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
               
              But how to achieve it...?
               
              Jacob


              -- 
              Peter Stevens, CSM, CSPO, CSP
              www.scrum-breakfast.com
              tel: +41 44 586 6450 
              
            • elisabethshendrickson
              Hi Jacob, What a marvelous coaching challenge! I wonder to what extent the senior engineer feeling the need for uninterrupted time is a symptom rather than the
              Message 6 of 23 , Feb 5, 2010
              • 0 Attachment
                Hi Jacob,

                What a marvelous coaching challenge!

                I wonder to what extent the senior engineer feeling the need for uninterrupted time is a symptom rather than the root problem. My suspicion is that his complaint is a very important clue to discover what's really going on with this team, and is a great example of how Scrum can make deeper problems visible.

                Maybe it's a symptom of everything-in-progress, nothing done.

                Maybe it's a symptom of Hero Syndrome with the senior dev trying to shoulder too much of the team's work.

                Maybe it's a symptom of lacking Agile engineering practices (unit testing, Continuous Integration).

                Maybe it's a symptom of insufficient backlog grooming/story definition leading to confusion & churn.

                Maybe it's a symptom of insufficient visibility or collaboration among team members.

                Maybe it's a symptom of something even bigger like lack of alignment on the team, lack of whole team thinking, larger issues around organizational incentives (e.g. rewarding "individual velocity"), or a deep, pervasive skill gap among the other team members.

                I hope you'll dig a little deeper to find out what's going on with the whole team and not just the senior dev who raised the issue.

                And I hope you'll let us know what you discover. I'll bet the resulting story will be a great coaching case study.

                Elisabeth
                ----
                Elisabeth Hendrickson
                http://www.qualitytree.com
                http://www.testobsessed.com

                --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                >
                > Hello everyone,
                >
                > In a retrospective meeting today, tempers, voices, and issues were raised
                > because of a team member wishing to set standards about using 'do not
                > disturb' mode during sprint days.
                >
                > The developer claims that to achieve his best velocity he needs to have a
                > certain amount of time get his brain into gear, and once in this gear he is
                > only getting fifteen minutes of work in before being interrupted (and once
                > interrupted he needs time to get the brain going again).
                >
                > He claims that such a process is leading to crappy development time and
                > reducing the team's effectiveness.
                >
                > His solution was to block out the entire team for two-hour stretches every
                > day, sometimes leading to him having a total of six hours when he simply
                > doesn't respond to team members.
                >
                > Other team members claim that this is counter-productive, and that it is
                > causing the team to fall apart. They claim that this behavior is
                > counter-scrum, and that if anything there should be more team discussions,
                > not less.
                >
                > The 'do not disturb' developer is a senior engineer, scrum master, and
                > partner in the company.
                >
                > It seems simple to limit his 'me' time to one single two-hour stretch per
                > day, but he doesn't see why he should accept this.
                >
                > Personally I think that the team needs to feel the impact of interrupting
                > this guy, and not just him. If we can achieve that then they will not
                > interrupt so frequently.
                >
                > But how to achieve it...?
                >
                > Jacob
                >
              • George Dinwiddie
                Jacob, Is the team working together in a common room, isolated from people working on other projects? Or working in cubicles? Or what? Are team members
                Message 7 of 23 , Feb 5, 2010
                • 0 Attachment
                  Jacob,

                  Is the team working together in a common room, isolated from people
                  working on other projects? Or working in cubicles? Or what?

                  Are team members pairing? Or working individually?

                  Is the team swarming over user stories? Or working on separate tasks
                  that get integrated later?

                  - George

                  Jacob wrote:
                  >
                  >
                  > Hello everyone,
                  >
                  > In a retrospective meeting today, tempers, voices, and issues were
                  > raised because of a team member wishing to set standards about using 'do
                  > not disturb' mode during sprint days.
                  >
                  > The developer claims that to achieve his best velocity he needs to have
                  > a certain amount of time get his brain into gear, and once in this gear
                  > he is only getting fifteen minutes of work in before being interrupted
                  > (and once interrupted he needs time to get the brain going again).
                  >
                  > He claims that such a process is leading to crappy development time and
                  > reducing the team's effectiveness.
                  >
                  > His solution was to block out the entire team for two-hour stretches
                  > every day, sometimes leading to him having a total of six hours when he
                  > simply doesn't respond to team members.
                  >
                  > Other team members claim that this is counter-productive, and that it is
                  > causing the team to fall apart. They claim that this behavior is
                  > counter-scrum, and that if anything there should be more team
                  > discussions, not less.
                  >
                  > The 'do not disturb' developer is a senior engineer, scrum master, and
                  > partner in the company.
                  >
                  > It seems simple to limit his 'me' time to one single two-hour stretch
                  > per day, but he doesn't see why he should accept this.
                  >
                  > Personally I think that the team needs to feel the impact of
                  > interrupting this guy, and not just him. If we can achieve that then
                  > they will not interrupt so frequently.
                  >
                  > But how to achieve it...?
                  >
                  > Jacob

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • John
                  Hi Jason, Before you could move this on I think there needs to be deeper understanding of why the engineer is being disturbed quite so frequently. Some
                  Message 8 of 23 , Feb 5, 2010
                  • 0 Attachment
                    Hi Jason,
                    Before you could move this on I think there needs to be deeper understanding of why the engineer is being disturbed quite so frequently. Some questions that spring to mind are (by no means an exhaustive list):
                    • Are they the SM for the team? Do they need to be?
                    • Are they the only person who understands something (domain/technology)? Can the team find a way to bring about knowledge transfer, reducing the reliance on a single person?
                    • Does the team automatically seek their approval before going down a particular path? Why is this?
                    Without knowing the cause of these interruptions, and whether they really want anything done to stop them, it is very hard to suggest a course of action. However, I wouldn't move to seek their removal until you've tried alternative routes of mediation.

                    John

                    --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                    >
                    > Hello everyone,
                    >
                    > In a retrospective meeting today, tempers, voices, and issues were raised
                    > because of a team member wishing to set standards about using 'do not
                    > disturb' mode during sprint days.
                    >
                    > The developer claims that to achieve his best velocity he needs to have a
                    > certain amount of time get his brain into gear, and once in this gear he is
                    > only getting fifteen minutes of work in before being interrupted (and once
                    > interrupted he needs time to get the brain going again).
                    >
                    > He claims that such a process is leading to crappy development time and
                    > reducing the team's effectiveness.
                    >
                    > His solution was to block out the entire team for two-hour stretches every
                    > day, sometimes leading to him having a total of six hours when he simply
                    > doesn't respond to team members.
                    >
                    > Other team members claim that this is counter-productive, and that it is
                    > causing the team to fall apart. They claim that this behavior is
                    > counter-scrum, and that if anything there should be more team discussions,
                    > not less.
                    >
                    > The 'do not disturb' developer is a senior engineer, scrum master, and
                    > partner in the company.
                    >
                    > It seems simple to limit his 'me' time to one single two-hour stretch per
                    > day, but he doesn't see why he should accept this.
                    >
                    > Personally I think that the team needs to feel the impact of interrupting
                    > this guy, and not just him. If we can achieve that then they will not
                    > interrupt so frequently.
                    >
                    > But how to achieve it...?
                    >
                    > Jacob
                    >
                  • Roy Morien
                    There has always been the concept of caves and commons (or was that commons and caves ?). I see nothing wrong wih someone wanting, and needing, do not
                    Message 9 of 23 , Feb 5, 2010
                    • 0 Attachment
                      There has always been the concept of 'caves and commons' (or was that 'commons and caves'?). I see nothing wrong wih someone wanting, and needing, 'do not disturb' time to get on with their job. Some people work well with their earplugs in listening to loud music, some people can work in a busy, noisy environment, other can't.
                       
                      I think this notion that everything is being done 'by the team' is interpreted incorrectly. Yes, the team is a collaborative unit that, together, is producing an outcome. But the team members actually do the work, usually operating in a solitary manner. Where they need to communicate, they should. But where they want some 'do not disturb' time, that is quite OK.
                       
                      The problem tha is being described is not one of 'do not disturb time' per se. It seems to me that the problem is that this is not appropriate to the roe that this developer is playing. He is, as stated 'a senior engineer, scrum master, and partner in the company'. That all implies to me that he really needs to be on tap as and when needed. If he wants to have a substantial amount of 'do not disturb' time, then he should fall back into the role of developer, and stop being the SM, stop being 'a senior engineer'. His role as a partner cannot be stopped, and in any case assumes tht he has other business oriented duties other than development of software. In his role as 'a senior engineer, scrum master, and partner in the company' then daily standup meeting is not enough. Other developers need him when they need him.
                       
                      Regards
                      Roy Morien
                       

                      To: scrumdevelopment@yahoogroups.com
                      From: jacob@...
                      Date: Fri, 5 Feb 2010 15:45:04 +0200
                      Subject: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                       
                      Hello everyone,
                       
                      In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
                       
                      The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
                       
                      He claims that such a process is leading to crappy development time and reducing the team's effectiveness.
                       
                      His solution was to block out the entire team for two-hour stretches every day, sometimes leading to him having a total of six hours when he simply doesn't respond to team members.
                       
                      Other team members claim that this is counter-productive, and that it is causing the team to fall apart. They claim that this behavior is counter-scrum, and that if anything there should be more team discussions, not less.
                       
                      The 'do not disturb' developer is a senior engineer, scrum master, and partner in the company.
                       
                      It seems simple to limit his 'me' time to one single two-hour stretch per day, but he doesn't see why he should accept this.
                       
                      Personally I think that the team needs to feel the impact of interrupting this guy, and not just him. If we can achieve that then they will not interrupt so frequently.
                       
                      But how to achieve it...?
                       
                      Jacob




                      Sell your old one fast! Time for a new car?
                    • photon_ent
                      Hi Jacob, I m going to go against the flow here :) When we first moved to agile, we had this problem in spades. Our situation was that there few a few senior
                      Message 10 of 23 , Feb 5, 2010
                      • 0 Attachment
                        Hi Jacob,

                        I'm going to go against the flow here :)

                        When we first moved to agile, we had this problem in spades.

                        Our situation was that there few a few senior people who knew the system inside out, and a bunch of newer people who didnt. The senior people were constantly getting interrupted on how does this work or how does that work. Their role had subtly changed from coding to training and mentoring, and its not something that they liked. During this time progress on the software was essentially stalled.

                        This is not an uncommon situation when you are transitioning from an old way of working to a new one.

                        *Ideally*, you want everyone collaborating all the time. But sometimes you need to balance things out as you transition to an environment that supports it.

                        Alistair Cockburn has a pattern called Cone of Silence. He describes it in detail over here - http://alistair.cockburn.us/The+cone+of+silence+and+related+project+management+strategies

                        The funny thing about cone of silence is that it goes against a lot of basic agile principles. But it can be a useful thing in a particular context.

                        In our situation we used the cone of silence for one day in a week. That day everyone just worked alone. The other four days were collaborative. Eventually the environment transitioned to one where we were able to remove the need for a cone of silence.

                        --
                        Siddharta Govindaraj

                        --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                        >
                        > Hello everyone,
                        >
                        > In a retrospective meeting today, tempers, voices, and issues were raised
                        > because of a team member wishing to set standards about using 'do not
                        > disturb' mode during sprint days.
                        >
                        > The developer claims that to achieve his best velocity he needs to have a
                        > certain amount of time get his brain into gear, and once in this gear he is
                        > only getting fifteen minutes of work in before being interrupted (and once
                        > interrupted he needs time to get the brain going again).
                        >
                        > He claims that such a process is leading to crappy development time and
                        > reducing the team's effectiveness.
                        >
                        > His solution was to block out the entire team for two-hour stretches every
                        > day, sometimes leading to him having a total of six hours when he simply
                        > doesn't respond to team members.
                        >
                        > Other team members claim that this is counter-productive, and that it is
                        > causing the team to fall apart. They claim that this behavior is
                        > counter-scrum, and that if anything there should be more team discussions,
                        > not less.
                        >
                        > The 'do not disturb' developer is a senior engineer, scrum master, and
                        > partner in the company.
                        >
                        > It seems simple to limit his 'me' time to one single two-hour stretch per
                        > day, but he doesn't see why he should accept this.
                        >
                        > Personally I think that the team needs to feel the impact of interrupting
                        > this guy, and not just him. If we can achieve that then they will not
                        > interrupt so frequently.
                        >
                        > But how to achieve it...?
                        >
                        > Jacob
                        >
                      • Michael James
                        In the team room, I ve noticed the team is like one living organism that goes through active periods and quiet periods. Tobias posted a time-lapse video that
                        Message 11 of 23 , Feb 5, 2010
                        • 0 Attachment
                          In the team room, I've noticed the team is like one living organism that goes through active periods and quiet periods. Tobias posted a time-lapse video that showed this pretty well. I am the type of person who normally prefers to work in silence, late at night. I found the team room and pair programming helped me focus in a different way, though there was still value in alone time.

                          I'd want to observe this team firsthand before prescribing a response. Interesting topic.

                          --mj

                          On Feb 5, 2010, at 8:40 PM, photon_ent wrote:

                          > Hi Jacob,
                          >
                          > I'm going to go against the flow here :)
                          >
                          > When we first moved to agile, we had this problem in spades.
                          >
                          > Our situation was that there few a few senior people who knew the system inside out, and a bunch of newer people who didnt. The senior people were constantly getting interrupted on how does this work or how does that work. Their role had subtly changed from coding to training and mentoring, and its not something that they liked. During this time progress on the software was essentially stalled.
                          >
                          > This is not an uncommon situation when you are transitioning from an old way of working to a new one.
                          >
                          > *Ideally*, you want everyone collaborating all the time. But sometimes you need to balance things out as you transition to an environment that supports it.
                          >
                          > Alistair Cockburn has a pattern called Cone of Silence. He describes it in detail over here - http://alistair.cockburn.us/The+cone+of+silence+and+related+project+management+strategies
                          >
                          > The funny thing about cone of silence is that it goes against a lot of basic agile principles. But it can be a useful thing in a particular context.
                          >
                          > In our situation we used the cone of silence for one day in a week. That day everyone just worked alone. The other four days were collaborative. Eventually the environment transitioned to one where we were able to remove the need for a cone of silence.
                          >
                          > --
                          > Siddharta Govindaraj
                          >
                          > --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                          >>
                          >> Hello everyone,
                          >>
                          >> In a retrospective meeting today, tempers, voices, and issues were raised
                          >> because of a team member wishing to set standards about using 'do not
                          >> disturb' mode during sprint days.
                          >>
                          >> The developer claims that to achieve his best velocity he needs to have a
                          >> certain amount of time get his brain into gear, and once in this gear he is
                          >> only getting fifteen minutes of work in before being interrupted (and once
                          >> interrupted he needs time to get the brain going again).
                          >>
                          >> He claims that such a process is leading to crappy development time and
                          >> reducing the team's effectiveness.
                          >>
                          >> His solution was to block out the entire team for two-hour stretches every
                          >> day, sometimes leading to him having a total of six hours when he simply
                          >> doesn't respond to team members.
                          >>
                          >> Other team members claim that this is counter-productive, and that it is
                          >> causing the team to fall apart. They claim that this behavior is
                          >> counter-scrum, and that if anything there should be more team discussions,
                          >> not less.
                          >>
                          >> The 'do not disturb' developer is a senior engineer, scrum master, and
                          >> partner in the company.
                          >>
                          >> It seems simple to limit his 'me' time to one single two-hour stretch per
                          >> day, but he doesn't see why he should accept this.
                          >>
                          >> Personally I think that the team needs to feel the impact of interrupting
                          >> this guy, and not just him. If we can achieve that then they will not
                          >> interrupt so frequently.
                          >>
                          >> But how to achieve it...?
                          >>
                          >> Jacob
                          >>
                          >
                          >
                          >
                          >
                          > ------------------------------------
                          >
                          > To Post a message, send it to: scrumdevelopment@...
                          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                          >
                          >
                          >
                        • Hariprakash Agrawal
                          I personally like to have some alone time whenever I need high degree of concentration and that happens pretty frequently. Most of the artists work that way. I
                          Message 12 of 23 , Feb 6, 2010
                          • 0 Attachment
                            I personally like to have some alone time whenever I need high degree of concentration and that happens pretty frequently. Most of the artists work that way. I remember that about 4-5 years ago, one senior developer complained of too many interruptions and in that small organizations, we initiated silence period of 2 hours and slowly everyone got used to it and we found good results. However, the team was not using scrum that time.

                            In this particular case, I think that the senior engineer cum partner can sacrifice the SM role as due to this, (s)he might get interrupted by other team members more frequently. Still, if situation does not improve than I think you need to look at other challenges in team.

                            Personally, I like the idea of aloneness but how long it should be, in collaborative environment, is debatable and may depend on team to team.


                            Regards,
                            Hariprakash Agrawal (Hari),
                            An Agile Coach (XP, Scrum), Certified Scrum Master, Trained Six Sigma Black Belt, CMMi Consultant, ISO 9001:2000 Lead Auditor, MTech (Reliability & Quality Engg) from IIT-KGP
                            http://opcord.com - OpCord provides trainings/consulting on many frameworks/processes and testing services for organizations


                            On Sat, Feb 6, 2010 at 11:11 AM, Michael James <michael@...> wrote:
                             

                            In the team room, I've noticed the team is like one living organism that goes through active periods and quiet periods. Tobias posted a time-lapse video that showed this pretty well. I am the type of person who normally prefers to work in silence, late at night. I found the team room and pair programming helped me focus in a different way, though there was still value in alone time.

                            I'd want to observe this team firsthand before prescribing a response. Interesting topic.

                            --mj



                            On Feb 5, 2010, at 8:40 PM, photon_ent wrote:

                            > Hi Jacob,
                            >
                            > I'm going to go against the flow here :)
                            >
                            > When we first moved to agile, we had this problem in spades.
                            >
                            > Our situation was that there few a few senior people who knew the system inside out, and a bunch of newer people who didnt. The senior people were constantly getting interrupted on how does this work or how does that work. Their role had subtly changed from coding to training and mentoring, and its not something that they liked. During this time progress on the software was essentially stalled.
                            >
                            > This is not an uncommon situation when you are transitioning from an old way of working to a new one.
                            >
                            > *Ideally*, you want everyone collaborating all the time. But sometimes you need to balance things out as you transition to an environment that supports it.
                            >
                            > Alistair Cockburn has a pattern called Cone of Silence. He describes it in detail over here - http://alistair.cockburn.us/The+cone+of+silence+and+related+project+management+strategies
                            >
                            > The funny thing about cone of silence is that it goes against a lot of basic agile principles. But it can be a useful thing in a particular context.
                            >
                            > In our situation we used the cone of silence for one day in a week. That day everyone just worked alone. The other four days were collaborative. Eventually the environment transitioned to one where we were able to remove the need for a cone of silence.
                            >
                            > --
                            > Siddharta Govindaraj
                            >
                            > --- In scrumdevelopment@yahoogroups.com, Jacob <jacob@...> wrote:
                            >>
                            >> Hello everyone,
                            >>
                            >> In a retrospective meeting today, tempers, voices, and issues were raised
                            >> because of a team member wishing to set standards about using 'do not
                            >> disturb' mode during sprint days.
                            >>
                            >> The developer claims that to achieve his best velocity he needs to have a
                            >> certain amount of time get his brain into gear, and once in this gear he is
                            >> only getting fifteen minutes of work in before being interrupted (and once
                            >> interrupted he needs time to get the brain going again).
                            >>
                            >> He claims that such a process is leading to crappy development time and
                            >> reducing the team's effectiveness.
                            >>
                            >> His solution was to block out the entire team for two-hour stretches every
                            >> day, sometimes leading to him having a total of six hours when he simply
                            >> doesn't respond to team members.
                            >>
                            >> Other team members claim that this is counter-productive, and that it is
                            >> causing the team to fall apart. They claim that this behavior is
                            >> counter-scrum, and that if anything there should be more team discussions,
                            >> not less.
                            >>
                            >> The 'do not disturb' developer is a senior engineer, scrum master, and
                            >> partner in the company.
                            >>
                            >> It seems simple to limit his 'me' time to one single two-hour stretch per
                            >> day, but he doesn't see why he should accept this.
                            >>
                            >> Personally I think that the team needs to feel the impact of interrupting
                            >> this guy, and not just him. If we can achieve that then they will not
                            >> interrupt so frequently.
                            >>
                            >> But how to achieve it...?
                            >>
                            >> Jacob
                            >>
                            >
                            >
                            >
                            >
                            > ------------------------------------

                            >
                            > To Post a message, send it to: scrumdevelopment@...
                            > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
                            >
                            >
                            >




                          • Adam Sroka
                            ... Cool, naptime! ... I get you, but I would have worded that first part a little differently (LOL.) Someone who does not like to be interrupted should not be
                            Message 13 of 23 , Feb 6, 2010
                            • 0 Attachment
                              On Sat, Feb 6, 2010 at 4:09 AM, Hariprakash Agrawal <haricha@...> wrote:
                              >
                              >
                              >
                              > I personally like to have some alone time whenever I need high degree of concentration and that happens pretty frequently. Most of the artists work that way. I remember that about 4-5 years ago, one senior developer complained of too many interruptions and in that small organizations, we initiated silence period of 2 hours and slowly everyone got used to it and we found good results. However, the team was not using scrum that time.
                              >

                              Cool, naptime!

                              > In this particular case, I think that the senior engineer cum partner can sacrifice the SM role as due to this, (s)he might get interrupted by other team members more frequently. Still, if situation does not improve than I think you need to look at other challenges in team.
                              >

                              I get you, but I would have worded that first part a little differently (LOL.)

                              Someone who does not like to be interrupted should not be a
                              Scrummaster, period. The Scrummaster's role is to serve the team. They
                              have to be available to the team during the whole day. That is their
                              job. If something else is more important then they aren't really being
                              a Scrummaster. So, let them be a senior whatever and find somebody who
                              actually wants to serve the team to be the Scrummaster.

                              > Personally, I like the idea of aloneness but how long it should be, in collaborative environment, is debatable and may depend on team to team.
                              >

                              I like to keep core hours, say 10:00-16:00. If people want to do
                              things that aren't collaborative they can do it before or after that
                              time, but that time is for the team. If people really like "aloneness"
                              they can come in really early or stay really late and be entirely
                              alone. But, they have to be with the team during the team part of the
                              day.

                              That doesn't work for every team in every situation, but it is a good
                              thing to try. Eventually, you will be more effective if you maximize
                              the amount of work that is done during the collaborative time and
                              minimize the amount done during "alone time" (In fact, I suggest you
                              just go home.)
                            • Michael James
                              ... Yes, that s it. I m there to help create team flow. That means I m the one who doesn t get to experience flow as often. --mj
                              Message 14 of 23 , Feb 6, 2010
                              • 0 Attachment
                                On Feb 6, 2010, at 1:22 PM, Adam Sroka wrote:

                                > Someone who does not like to be interrupted should not be a
                                > Scrummaster, period. The Scrummaster's role is to serve the team.

                                Yes, that's it. I'm there to help create team flow. That means I'm the one who doesn't get to experience flow as often.

                                --mj
                              • Dan Rawsthorne
                                I think the SM s flow is the Team s flow. You really aren t your own person... the SM does not exist without his team. That s why it s a role, and not a
                                Message 15 of 23 , Feb 6, 2010
                                • 0 Attachment
                                  I think the SM's flow is the Team's flow. You really aren't your own
                                  person... the SM does not exist without his team. That's why it's a
                                  role, and not a person, I guess.

                                  Dan Rawsthorne, PhD, CST
                                  Senior Coach, Danube Technologies
                                  dan@..., 425-269-8628



                                  Michael James wrote:
                                  >
                                  > On Feb 6, 2010, at 1:22 PM, Adam Sroka wrote:
                                  >
                                  > > Someone who does not like to be interrupted should not be a
                                  > > Scrummaster, period. The Scrummaster's role is to serve the team.
                                  >
                                  > Yes, that's it. I'm there to help create team flow. That means I'm the
                                  > one who doesn't get to experience flow as often.
                                  >
                                  > --mj
                                  >
                                  >
                                • David Stanek
                                  ... The developer is absolutely correct. Sometimes I need to just sit down and write code. Non-essential distractions just slow me down and usually they can
                                  Message 16 of 23 , Feb 7, 2010
                                  • 0 Attachment
                                    On Fri, Feb 5, 2010 at 8:45 AM, Jacob <jacob@...> wrote:
                                     

                                    Hello everyone,
                                     
                                    In a retrospective meeting today, tempers, voices, and issues were raised because of a team member wishing to set standards about using 'do not disturb' mode during sprint days.
                                     
                                    The developer claims that to achieve his best velocity he needs to have a certain amount of time get his brain into gear, and once in this gear he is only getting fifteen minutes of work in before being interrupted (and once interrupted he needs time to get the brain going again).
                                     
                                    He claims that such a process is leading to crappy development time and reducing the team's effectiveness.

                                    The developer is absolutely correct. Sometimes I need to just sit down and write code. Non-essential distractions just slow me down and usually they can wait an hour or so.


                                    --
                                    David
                                    blog: http://www.traceback.org
                                    twitter: http://twitter.com/dstanek
                                  • Ron Jeffries
                                    Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you ... I used to think that as well. Today, I m not so sure. Working with a pair, in a room, seems
                                    Message 17 of 23 , Feb 7, 2010
                                    • 0 Attachment
                                      Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                      wrote:

                                      > The developer is absolutely correct. Sometimes I need to just sit down and
                                      > write code. Non-essential distractions just slow me down and usually they
                                      > can wait an hour or so.

                                      I used to think that as well. Today, I'm not so sure. Working with a
                                      pair, in a room, seems to me to make my own work go more smoothly,
                                      and that of the team as well.

                                      What I miss is that joy of proving that I am once again smarter than
                                      the computer, and smarter than myself, by making some complex piece
                                      of code work against its will. As I see it, that's not much of a
                                      loss.

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      We know less about the project today than at any time in the future.
                                      -- Chet Hendrickson
                                      You mean today is the dumbest day of the rest of my life?
                                      -- Ron Jeffries
                                    • David Stanek
                                      ... In my mind hacking on code may mean I m alone or with a pair. Either way you I need to be able to focus on the task at hand. I m constantly being
                                      Message 18 of 23 , Feb 7, 2010
                                      • 0 Attachment
                                        On Sun, Feb 7, 2010 at 11:44 AM, Ron Jeffries <ronjeffries@...> wrote:
                                         

                                        Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                        wrote:



                                        > The developer is absolutely correct. Sometimes I need to just sit down and
                                        > write code. Non-essential distractions just slow me down and usually they
                                        > can wait an hour or so.

                                        I used to think that as well. Today, I'm not so sure. Working with a
                                        pair, in a room, seems to me to make my own work go more smoothly,
                                        and that of the team as well.

                                        What I miss is that joy of proving that I am once again smarter than
                                        the computer, and smarter than myself, by making some complex piece
                                        of code work against its will. As I see it, that's not much of a
                                        loss.

                                         
                                        In my mind hacking on code may mean I'm alone or with a pair. Either way you I need to be able to focus on the task at hand. I'm constantly being distracted by team members for things that are unrelated to the coding I am doing. I envisioned the developer from the original post to be getting the 'can you help me?' and 'what are you working on?' questions.


                                        --
                                        David
                                        blog: http://www.traceback.org
                                        twitter: http://twitter.com/dstanek
                                      • Ron Jeffries
                                        Hello, David. On Sunday, February 7, 2010, at 12:02:13 PM, you ... Helping may be more important than whatever one is doing. And I m curious why they wouldn t
                                        Message 19 of 23 , Feb 7, 2010
                                        • 0 Attachment
                                          Hello, David. On Sunday, February 7, 2010, at 12:02:13 PM, you
                                          wrote:

                                          > I envisioned the developer from the original post to be getting the
                                          > 'can you help me?' and 'what are you working on?' questions.

                                          Helping may be more important than whatever one is doing. And I'm
                                          curious why they wouldn't know the answer to the second question.

                                          Ron Jeffries
                                          www.XProgramming.com
                                          www.xprogramming.com/blog
                                          Those who believe complexity is elegant or required don't understand
                                          the problem. -- John Streiff
                                        • Ted Young
                                          As a dev lead, I get interrupted a lot for questions from the team -- mostly related to our project -- and while it certainly affects my personal productivity,
                                          Message 20 of 23 , Feb 7, 2010
                                          • 0 Attachment
                                            As a dev lead, I get interrupted a lot for questions from the team -- mostly related to our project -- and while it certainly affects my personal productivity, the important thing is that it increases the _team's_ productivity. But even for other team members, the fact that we're constantly pairing means the frequency of questions is low and when they do come up, it's great to have 3 or 4 people discussing it (because one pair came over to ask another pair).

                                            If, however, the team is getting interrupted by "non-essential" questions, then it's my job to keep that to a minimum and, more importantly, figure out the reason such questions are being asked.

                                            ;ted


                                            On Sun, Feb 7, 2010 at 9:02 AM, David Stanek <dstanek@...> wrote:




                                            On Sun, Feb 7, 2010 at 11:44 AM, Ron Jeffries <ronjeffries@...> wrote:
                                             

                                            Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                            wrote:



                                            > The developer is absolutely correct. Sometimes I need to just sit down and
                                            > write code. Non-essential distractions just slow me down and usually they
                                            > can wait an hour or so.

                                            I used to think that as well. Today, I'm not so sure. Working with a
                                            pair, in a room, seems to me to make my own work go more smoothly,
                                            and that of the team as well.

                                            What I miss is that joy of proving that I am once again smarter than
                                            the computer, and smarter than myself, by making some complex piece
                                            of code work against its will. As I see it, that's not much of a
                                            loss.

                                             
                                            In my mind hacking on code may mean I'm alone or with a pair. Either way you I need to be able to focus on the task at hand. I'm constantly being distracted by team members for things that are unrelated to the coding I am doing. I envisioned the developer from the original post to be getting the 'can you help me?' and 'what are you working on?' questions.

                                          • Roy Morien
                                            But how do you measure your productivity as a dev lead? If mentoring others, assisting them, answering their questions etc. is part and parcel of your job,
                                            Message 21 of 23 , Feb 7, 2010
                                            • 0 Attachment
                                              But how do you measure your 'productivity' as a dev lead? If mentoring others, assisting them, answering their questions etc. is part and parcel of your job, then surely you are being 'productive' if you are answering 'lots of questions' about the project.
                                               
                                              But at a more general level about this topic, years ago I developed the famous Morien Philosophy of the Unemployed Youth ... maybe you've heard of it?  
                                               
                                              Basically, it goes like this ... many many times in my career I have been in the situation where I was struggling with some code problem or other. Often just to vent my frustration as much as anything else I would explain my problem to someone else. Frequently, and I mean most of the time, the mere fact of trying to explain the problem to someone else seemed to enable me to gather my thoughts and the solution became clear, without a word being spoken by the other listener. So, I figured that one way to solve the youth unemployment problem was to hire a number of said youths for no other purpose but to be sounding boards for other people's problems. They didn't need to know anything, just listen with rapt attention while the problem-holder untangled the problem him or herself.
                                               
                                              People need to be able to try to explain their problem to someone, and the solution will so often reveal itself thereby.
                                               
                                              Such is the power of personal interaction and face-to-face communication. This seems inherent (not inherit, by the way) in pair programming, and the idiom of 'two heads are better than one'.
                                               
                                              So, as a dev lead being 'interupted' so often, it seems to me that you are doing your job quite well. If the others thought you were a dud, they would avoid asking you, I think.
                                               
                                              Regards,
                                              Roy Morien
                                               

                                              To: scrumdevelopment@yahoogroups.com
                                              From: tedyoung@...
                                              Date: Sun, 7 Feb 2010 19:00:08 -0800
                                              Subject: Re: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                               
                                              As a dev lead, I get interrupted a lot for questions from the team -- mostly related to our project -- and while it certainly affects my personal productivity, the important thing is that it increases the _team's_ productivity. But even for other team members, the fact that we're constantly pairing means the frequency of questions is low and when they do come up, it's great to have 3 or 4 people discussing it (because one pair came over to ask another pair).

                                              If, however, the team is getting interrupted by "non-essential" questions, then it's my job to keep that to a minimum and, more importantly, figure out the reason such questions are being asked.

                                              ;ted


                                              On Sun, Feb 7, 2010 at 9:02 AM, David Stanek <dstanek@dstanek. com> wrote:




                                              On Sun, Feb 7, 2010 at 11:44 AM, Ron Jeffries <ronjeffries@ acm.org> wrote:
                                               

                                              Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                              wrote:



                                              > The developer is absolutely correct. Sometimes I need to just sit down and
                                              > write code. Non-essential distractions just slow me down and usually they
                                              > can wait an hour or so.

                                              I used to think that as well. Today, I'm not so sure. Working with a
                                              pair, in a room, seems to me to make my own work go more smoothly,
                                              and that of the team as well.

                                              What I miss is that joy of proving that I am once again smarter than
                                              the computer, and smarter than myself, by making some complex piece
                                              of code work against its will. As I see it, that's not much of a
                                              loss.

                                               
                                              In my mind hacking on code may mean I'm alone or with a pair. Either way you I need to be able to focus on the task at hand. I'm constantly being distracted by team members for things that are unrelated to the coding I am doing. I envisioned the developer from the original post to be getting the 'can you help me?' and 'what are you working on?' questions.




                                              Start searching NOW! Search for properties that match your lifestyle!
                                            • Steve Ropa
                                              I love the idea. I have also benefited often from just explaining my solution to someone. I ll never forget the time I made it about 75% of the way through
                                              Message 22 of 23 , Feb 8, 2010
                                              • 0 Attachment
                                                I love the idea.  I  have also benefited often from just explaining my solution to someone.  I'll never forget the time I made it about 75% of the way through explaining  this truly elegant solution for thread management I had implemented when I saw the glazed look in my victi... er partner's eyes.  I had successfully created a way of managing threads that was so ridiculously complex that I couldn't even explain what I was doing to a peer....
                                                 
                                                 

                                                Sent: Sunday, February 07, 2010 8:40 PM
                                                Subject: RE: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                                 

                                                But how do you measure your 'productivity' as a dev lead? If mentoring others, assisting them, answering their questions etc. is part and parcel of your job, then surely you are being 'productive' if you are answering 'lots of questions' about the project.
                                                 
                                                But at a more general level about this topic, years ago I developed the famous Morien Philosophy of the Unemployed Youth ... maybe you've heard of it?  
                                                 
                                                Basically, it goes like this ... many many times in my career I have been in the situation where I was struggling with some code problem or other. Often just to vent my frustration as much as anything else I would explain my problem to someone else. Frequently, and I mean most of the time, the mere fact of trying to explain the problem to someone else seemed to enable me to gather my thoughts and the solution became clear, without a word being spoken by the other listener. So, I figured that one way to solve the youth unemployment problem was to hire a number of said youths for no other purpose but to be sounding boards for other people's problems. They didn't need to know anything, just listen with rapt attention while the problem-holder untangled the problem him or herself.
                                                 
                                                People need to be able to try to explain their problem to someone, and the solution will so often reveal itself thereby.
                                                 
                                                Such is the power of personal interaction and face-to-face communication. This seems inherent (not inherit, by the way) in pair programming, and the idiom of 'two heads are better than one'.
                                                 
                                                So, as a dev lead being 'interupted' so often, it seems to me that you are doing your job quite well. If the others thought you were a dud, they would avoid asking you, I think.
                                                 
                                                Regards,
                                                Roy Morien
                                                 


                                                To: scrumdevelopment@ yahoogroups. com
                                                From: tedyoung@gmail. com
                                                Date: Sun, 7 Feb 2010 19:00:08 -0800
                                                Subject: Re: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                                 
                                                As a dev lead, I get interrupted a lot for questions from the team -- mostly related to our project -- and while it certainly affects my personal productivity, the important thing is that it increases the _team's_ productivity. But even for other team members, the fact that we're constantly pairing means the frequency of questions is low and when they do come up, it's great to have 3 or 4 people discussing it (because one pair came over to ask another pair).

                                                If, however, the team is getting interrupted by "non-essential" questions, then it's my job to keep that to a minimum and, more importantly, figure out the reason such questions are being asked.

                                                ;ted


                                                On Sun, Feb 7, 2010 at 9:02 AM, David Stanek <dstanek@dstanek. com> wrote:




                                                On Sun, Feb 7, 2010 at 11:44 AM, Ron Jeffries <ronjeffries@ acm.org> wrote:
                                                 

                                                Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                                wrote:



                                                > The developer is absolutely correct. Sometimes I need to just sit down and
                                                > write code. Non-essential distractions just slow me down and usually they
                                                > can wait an hour or so.

                                                I used to think that as well. Today, I'm not so sure. Working with a
                                                pair, in a room, seems to me to make my own work go more smoothly,
                                                and that of the team as well.

                                                What I miss is that joy of proving that I am once again smarter than
                                                the computer, and smarter than myself, by making some complex piece
                                                of code work against its will. As I see it, that's not much of a
                                                loss.

                                                 
                                                In my mind hacking on code may mean I'm alone or with a pair. Either way you I need to be able to focus on the task at hand. I'm constantly being distracted by team members for things that are unrelated to the coding I am doing. I envisioned the developer from the original post to be getting the 'can you help me?' and 'what are you working on?' questions.




                                                Start searching NOW! Search for properties that match your lifestyle!

                                              • Roy Morien
                                                Yes, the elegant simplicity of your solution can reveal itself when you explain it to someone ... OR ... While this is not especially appropriate to this
                                                Message 23 of 23 , Feb 8, 2010
                                                • 0 Attachment
                                                  Yes, the elegant simplicity of your solution can reveal itself when you explain it to someone ... OR ...
                                                   
                                                  While this is not especially appropriate to this thread, I have a funny 'student' story along these lines. One function that I asked the students to write was to calculate the number of days between two dates. Anyway, one student, who had a rather high opinion of himself and this showed by a rather disrespectful and somewhat arrogant attitude towards me, challenged me about the complexity of the function, and how I was expecting too much from the students. I was somewhat puzzled by his problem, and asked him to show me what he was doing. Somewhat to my astonishment he showed me about 3 pages of code. He had taken the two dates as strings, broken them down into day, month, year, and proceeded to calculate from there. His attitude when showing me was 'SEE ... this is too complex ... I TOLD YOU SO!!'. sort of triumphant manner.
                                                   
                                                  When I doodled the 1 line solution to the problem (ie: NumberOfDays = LaterDate - EarlierDate) he got a bit upset that I wasn't paying attention. So I told him ... but that's the solution ... one line of code ... date arithmetic. He left somewhat quieter than he had arrived.
                                                   
                                                  So Yes, we can sometimes find the most complex and unnecessary way to achieve a simple solution.
                                                   
                                                  Regards
                                                  Roy Morien 

                                                  To: scrumdevelopment@yahoogroups.com
                                                  From: theropas@...
                                                  Date: Mon, 8 Feb 2010 08:37:28 -0700
                                                  Subject: Re: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                                   
                                                  I love the idea.  I  have also benefited often from just explaining my solution to someone.  I'll never forget the time I made it about 75% of the way through explaining  this truly elegant solution for thread management I had implemented when I saw the glazed look in my victi... er partner's eyes.  I had successfully created a way of managing threads that was so ridiculously complex that I couldn't even explain what I was doing to a peer....
                                                   
                                                   

                                                  Sent: Sunday, February 07, 2010 8:40 PM
                                                  Subject: RE: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                                   

                                                  But how do you measure your 'productivity' as a dev lead? If mentoring others, assisting them, answering their questions etc. is part and parcel of your job, then surely you are being 'productive' if you are answering 'lots of questions' about the project.
                                                   
                                                  But at a more general level about this topic, years ago I developed the famous Morien Philosophy of the Unemployed Youth ... maybe you've heard of it?  
                                                   
                                                  Basically, it goes like this ... many many times in my career I have been in the situation where I was struggling with some code problem or other. Often just to vent my frustration as much as anything else I would explain my problem to someone else. Frequently, and I mean most of the time, the mere fact of trying to explain the problem to someone else seemed to enable me to gather my thoughts and the solution became clear, without a word being spoken by the other listener. So, I figured that one way to solve the youth unemployment problem was to hire a number of said youths for no other purpose but to be sounding boards for other people's problems. They didn't need to know anything, just listen with rapt attention while the problem-holder untangled the problem him or herself.
                                                   
                                                  People need to be able to try to explain their problem to someone, and the solution will so often reveal itself thereby.
                                                   
                                                  Such is the power of personal interaction and face-to-face communication. This seems inherent (not inherit, by the way) in pair programming, and the idiom of 'two heads are better than one'.
                                                   
                                                  So, as a dev lead being 'interupted' so often, it seems to me that you are doing your job quite well. If the others thought you were a dud, they would avoid asking you, I think.
                                                   
                                                  Regards,
                                                  Roy Morien
                                                   


                                                  To: scrumdevelopment@ yahoogroups. com
                                                  From: tedyoung@gmail. com
                                                  Date: Sun, 7 Feb 2010 19:00:08 -0800
                                                  Subject: Re: [scrumdevelopment] Developers in 'Do Not Disturb' mode breaking the 'team' ?

                                                   
                                                  As a dev lead, I get interrupted a lot for questions from the team -- mostly related to our project -- and while it certainly affects my personal productivity, the important thing is that it increases the _team's_ productivity. But even for other team members, the fact that we're constantly pairing means the frequency of questions is low and when they do come up, it's great to have 3 or 4 people discussing it (because one pair came over to ask another pair).

                                                  If, however, the team is getting interrupted by "non-essential" questions, then it's my job to keep that to a minimum and, more importantly, figure out the reason such questions are being asked.

                                                  ;ted


                                                  On Sun, Feb 7, 2010 at 9:02 AM, David Stanek <dstanek@dstanek. com> wrote:




                                                  On Sun, Feb 7, 2010 at 11:44 AM, Ron Jeffries <ronjeffries@ acm.org> wrote:
                                                   

                                                  Hello, David. On Sunday, February 7, 2010, at 9:54:48 AM, you
                                                  wrote:



                                                  > The developer is absolutely correct. Sometimes I need to just sit down and
                                                  > write code. Non-essential distractions just slow me down and usually they
                                                  > can wait an hour or so.

                                                  I used to think that as well. Today, I'm not so sure. Working with a
                                                  pair, in a room, seems to me to make my own work go more smoothly,
                                                  and that of the team as well.

                                                  What I miss is that joy of proving that I am once again smarter than
                                                  the computer, and smarter than myself, by making some complex piece
                                                  of code work against its will. As I see it, that's not much of a
                                                  loss.

                                                   
                                                  In my mind hacking on code may mean I'm alone or with a pair. Either way you I need to be able to focus on the task at hand. I'm constantly being distracted by team members for things that are unrelated to the coding I am doing. I envisioned the developer from the original post to be getting the 'can you help me?' and 'what are you working on?' questions.




                                                  Start searching NOW! Search for properties that match your lifestyle!





                                                  Learn how Video chat with Windows Live Messenger
                                                Your message has been successfully submitted and would be delivered to recipients shortly.