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

Re: Organizational Patterns of Agile Software Development

Expand Messages
  • Victor Szalvay
    Alister, I apologize for the late follow up, I seemed to have missed your reply in the flood of messages that engulfed the thread. In my original post, I
    Message 1 of 97 , Oct 28, 2004
    • 0 Attachment
      Alister, I apologize for the late follow up, I seemed to have missed
      your reply in the flood of messages that engulfed the thread.

      In my original post, I pointed out actually that you did in fact
      support "cross-functional teams":
      "I should make clear that it in general the
      patterns support cross-functional teams, having each role represented
      on each team (HolisticDiversity)."
      http://groups.yahoo.com/group/scrumdevelopment/message/4529

      My point was about your reference in the "Example" section to project
      Winifred (below) that encourages specialization over "cross-functional
      team members" (not just cross functional teams!). So my post was
      really about reconciling the fact that your pattern emphasizes
      specialists while Scrum generally encourages "generalists" to bridge
      communication gaps between roles.

      Since both were derived empirically, I was curious what people were
      recommending for their teams today.

      You are right though that "TeamPerTask" doesn't really make sense as a
      name. I think a better name might be:
      SubteamHandlesDiversion
      or something descriptive like that.

      Thanks for your follow up, it's exciting to get your feedback on this.

      -- Victor Szalvay


      --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@a...>
      wrote:
      >
      > --- In scrumdevelopment@yahoogroups.com, "Victor Szalvay"
      > <victor@d...> wrote:
      > >
      > > My only caution would be to newbie scrummers because some of the
      > > patterns contradict Scrum principles. For example, I posted a few
      > > weeks ago about a pattern called "TeamPerTask":
      > > http://groups.yahoo.com/group/scrumdevelopment/message/4529
      >
      > Victor,
      >
      > I only just noticed that append you reference ... the key bits
      being:
      > <<
      > At first read, the Coplien Org pattern TeamPerTask** (two stars for
      > highest confidence) sounds a lot like SacrificeOnePerson* with the
      > principal idea being SomeoneAlwaysMakesProgress*. But reading a bit
      > deeper I found that this pattern actually strongly discourages
      "cross-
      > functional team members". I should make clear that it in general the
      > patterns support cross-functional teams, having each role
      represented
      > on each team (HolisticDiversity). But TeamPerTask argues that cross-
      > functional team *members* are actually less productive because
      "flow"
      > time is interrupted (quoting the pattern...
      > >>
      >
      > Mea culpa - all of those patterns you reference are ones I
      > contributed (TeamPerTask, SomeoneAlwaysMakesProgress,
      > HolisticDiversity) and are written up both on my site and in my
      first
      > book Surviving OO Projects. Jim and Neil tidied them up and
      > integrated them into their material. So I can say as the source
      that
      > TeamPerTask is not particularly intended to reduce cross-functional
      > teams ...
      >
      > ... and so we get to the problem itself. Why on earth is it called
      > TeamPerTask?
      >
      > I just went and reread it on my website for the first time in a
      > while, using the glasses you just put on for me, and my reaction
      > was, "What on earth is this thing talking about? What is he trying
      to
      > say?"
      >
      > And the problem is with the name. The problem is, as we give these
      > patterns names, that with our then-thinking-modes in place, the
      name
      > is abundantly clear and Obviously means exactly what we're thinking
      > about ... except that to another person coming from a different set
      > of thoughts, the name triggers an entirely different set of
      thoughts.
      > I had this problem with one of my patterns, GoldRush (my favorite),
      > which at that time had a different name, and an IBM project manager
      > was busy saying, "Yes, we apply that one all the time."
      > And I thought to myself - there's no way he's doing that pattern!
      and
      > so digging deeper I found that he was doing the opposite of what I
      > intended but had somehow taken from the name of the pattern to mean
      > exactly what he was doing. So I tried to come up with a nam that he
      > couldn't possibly want to claim he was doing, namely GoldRush, to
      > make sure people like him wouldn't claim they were doing it.
      >
      > The same seems to have happened with Team Per Task. Tell me, would
      > it make any more sense if it were reversed and called "Task per
      > Team"? I'm not even sure at this point that that would work.
      >
      > Let's look at what the pattern is about, rather than the name. The
      > recommended action is (at this point I'm working from
      > http://alistair.cockburn.us/crystal/articles/prr
      p/projectriskreduction
      > patterns.html)
      > <<Sort the activities so that each team has a primary task with
      > additional, sympathetic activities. Sitting in meetings, answering
      > phone calls, writing reports, for example, are non-sympathetic to
      > designing software. Arrange it so that each team can focus on its
      > primary task, and each task has a dedicated team member. >>
      >
      > and from the principles:
      > <<Certain pairs of activities are more mutually distracting that
      > others. ... Sitting in meetings, answering questions and time on
      the
      > telephone are major distracters to design flow. Therefore the
      > recommendation to group tasks into sympathetic sets. Requirements
      and
      > analysis involve meetings, reading, and writing. Design and
      > programming require concentration on the implementation technology
      > and keeping a great number of details in the head.
      > >>
      >
      > and finally, the pattern itself is categorized by primary purpose,
      > and this one is put into the category Distractions (not team
      > composition).
      >
      > The pattern's makes "the recommendation to group tasks into
      > sympathetic sets". This is what the pattern is about.
      > Somewhere around here, I asked myself, "Then why is it called Team
      > per Task?" and didn't come up with a good answer. Seemingly, I was
      > thinking about a 'set of sympathetic tasks', and suggesting that
      > people be given role assignments along those lines.
      >
      > Further in the pattern, I go on to make it clear that we were using
      > cross-functional teams: "Requirements gathering and analysis went
      > with designated people in each team, and design and programming
      went
      > with the others. The result was that the requirements/analysis
      people
      > sat in meetings, read and wrote specs, examined interfaces and the
      > like. They communicated their findings to the designer/programmers
      -
      > orally, for the most part, since they were closely linked on the
      same
      > team ( Holistic Diversity ). "
      >
      > Not to make an excuse. I wrote this pattern back in 1997, and only
      > worked out what was wrong with the writing when you showed up with
      a
      > particularly different view of it than I had in mind. Starting
      today
      > I no longer like the name, although the advice is still sound.
      >
      > What might this pattern really be called?
      >
      > (p.s. you asked about removing person specialists altogether. The
      > pattern has something to say about this: "Project Winifred tried
      > having each person do requirements, analysis, design and
      programming.
      > We thought the developers would enjoy the change of activity, that
      > this would reduce the meetings and bureaucratic documentation
      > exchanged between people. What happened was that the first two
      > activities were so different from the latter two that people were
      > unable to switch easily between them. After having attended and
      > documented meetings for much of the day, it was difficult to start
      > working on the design and programming. As with bug-fixing / new-
      > development, every time a designer was pulled away from her or his
      > work, it cost an additional hour to recover the train of thought. "
      >
      > So I also learned that some specialization is valuable.)
      >
      > apologies for having messed up on this -
      > - Alistair
    • Victor Szalvay
      Alister, I apologize for the late follow up, I seemed to have missed your reply in the flood of messages that engulfed the thread. In my original post, I
      Message 97 of 97 , Oct 28, 2004
      • 0 Attachment
        Alister, I apologize for the late follow up, I seemed to have missed
        your reply in the flood of messages that engulfed the thread.

        In my original post, I pointed out actually that you did in fact
        support "cross-functional teams":
        "I should make clear that it in general the
        patterns support cross-functional teams, having each role represented
        on each team (HolisticDiversity)."
        http://groups.yahoo.com/group/scrumdevelopment/message/4529

        My point was about your reference in the "Example" section to project
        Winifred (below) that encourages specialization over "cross-functional
        team members" (not just cross functional teams!). So my post was
        really about reconciling the fact that your pattern emphasizes
        specialists while Scrum generally encourages "generalists" to bridge
        communication gaps between roles.

        Since both were derived empirically, I was curious what people were
        recommending for their teams today.

        You are right though that "TeamPerTask" doesn't really make sense as a
        name. I think a better name might be:
        SubteamHandlesDiversion
        or something descriptive like that.

        Thanks for your follow up, it's exciting to get your feedback on this.

        -- Victor Szalvay


        --- In scrumdevelopment@yahoogroups.com, "aacockburn" <acockburn@a...>
        wrote:
        >
        > --- In scrumdevelopment@yahoogroups.com, "Victor Szalvay"
        > <victor@d...> wrote:
        > >
        > > My only caution would be to newbie scrummers because some of the
        > > patterns contradict Scrum principles. For example, I posted a few
        > > weeks ago about a pattern called "TeamPerTask":
        > > http://groups.yahoo.com/group/scrumdevelopment/message/4529
        >
        > Victor,
        >
        > I only just noticed that append you reference ... the key bits
        being:
        > <<
        > At first read, the Coplien Org pattern TeamPerTask** (two stars for
        > highest confidence) sounds a lot like SacrificeOnePerson* with the
        > principal idea being SomeoneAlwaysMakesProgress*. But reading a bit
        > deeper I found that this pattern actually strongly discourages
        "cross-
        > functional team members". I should make clear that it in general the
        > patterns support cross-functional teams, having each role
        represented
        > on each team (HolisticDiversity). But TeamPerTask argues that cross-
        > functional team *members* are actually less productive because
        "flow"
        > time is interrupted (quoting the pattern...
        > >>
        >
        > Mea culpa - all of those patterns you reference are ones I
        > contributed (TeamPerTask, SomeoneAlwaysMakesProgress,
        > HolisticDiversity) and are written up both on my site and in my
        first
        > book Surviving OO Projects. Jim and Neil tidied them up and
        > integrated them into their material. So I can say as the source
        that
        > TeamPerTask is not particularly intended to reduce cross-functional
        > teams ...
        >
        > ... and so we get to the problem itself. Why on earth is it called
        > TeamPerTask?
        >
        > I just went and reread it on my website for the first time in a
        > while, using the glasses you just put on for me, and my reaction
        > was, "What on earth is this thing talking about? What is he trying
        to
        > say?"
        >
        > And the problem is with the name. The problem is, as we give these
        > patterns names, that with our then-thinking-modes in place, the
        name
        > is abundantly clear and Obviously means exactly what we're thinking
        > about ... except that to another person coming from a different set
        > of thoughts, the name triggers an entirely different set of
        thoughts.
        > I had this problem with one of my patterns, GoldRush (my favorite),
        > which at that time had a different name, and an IBM project manager
        > was busy saying, "Yes, we apply that one all the time."
        > And I thought to myself - there's no way he's doing that pattern!
        and
        > so digging deeper I found that he was doing the opposite of what I
        > intended but had somehow taken from the name of the pattern to mean
        > exactly what he was doing. So I tried to come up with a nam that he
        > couldn't possibly want to claim he was doing, namely GoldRush, to
        > make sure people like him wouldn't claim they were doing it.
        >
        > The same seems to have happened with Team Per Task. Tell me, would
        > it make any more sense if it were reversed and called "Task per
        > Team"? I'm not even sure at this point that that would work.
        >
        > Let's look at what the pattern is about, rather than the name. The
        > recommended action is (at this point I'm working from
        > http://alistair.cockburn.us/crystal/articles/prr
        p/projectriskreduction
        > patterns.html)
        > <<Sort the activities so that each team has a primary task with
        > additional, sympathetic activities. Sitting in meetings, answering
        > phone calls, writing reports, for example, are non-sympathetic to
        > designing software. Arrange it so that each team can focus on its
        > primary task, and each task has a dedicated team member. >>
        >
        > and from the principles:
        > <<Certain pairs of activities are more mutually distracting that
        > others. ... Sitting in meetings, answering questions and time on
        the
        > telephone are major distracters to design flow. Therefore the
        > recommendation to group tasks into sympathetic sets. Requirements
        and
        > analysis involve meetings, reading, and writing. Design and
        > programming require concentration on the implementation technology
        > and keeping a great number of details in the head.
        > >>
        >
        > and finally, the pattern itself is categorized by primary purpose,
        > and this one is put into the category Distractions (not team
        > composition).
        >
        > The pattern's makes "the recommendation to group tasks into
        > sympathetic sets". This is what the pattern is about.
        > Somewhere around here, I asked myself, "Then why is it called Team
        > per Task?" and didn't come up with a good answer. Seemingly, I was
        > thinking about a 'set of sympathetic tasks', and suggesting that
        > people be given role assignments along those lines.
        >
        > Further in the pattern, I go on to make it clear that we were using
        > cross-functional teams: "Requirements gathering and analysis went
        > with designated people in each team, and design and programming
        went
        > with the others. The result was that the requirements/analysis
        people
        > sat in meetings, read and wrote specs, examined interfaces and the
        > like. They communicated their findings to the designer/programmers
        -
        > orally, for the most part, since they were closely linked on the
        same
        > team ( Holistic Diversity ). "
        >
        > Not to make an excuse. I wrote this pattern back in 1997, and only
        > worked out what was wrong with the writing when you showed up with
        a
        > particularly different view of it than I had in mind. Starting
        today
        > I no longer like the name, although the advice is still sound.
        >
        > What might this pattern really be called?
        >
        > (p.s. you asked about removing person specialists altogether. The
        > pattern has something to say about this: "Project Winifred tried
        > having each person do requirements, analysis, design and
        programming.
        > We thought the developers would enjoy the change of activity, that
        > this would reduce the meetings and bureaucratic documentation
        > exchanged between people. What happened was that the first two
        > activities were so different from the latter two that people were
        > unable to switch easily between them. After having attended and
        > documented meetings for much of the day, it was difficult to start
        > working on the design and programming. As with bug-fixing / new-
        > development, every time a designer was pulled away from her or his
        > work, it cost an additional hour to recover the train of thought. "
        >
        > So I also learned that some specialization is valuable.)
        >
        > apologies for having messed up on this -
        > - Alistair
      Your message has been successfully submitted and would be delivered to recipients shortly.