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

Re: [XP] User-stories for components

Expand Messages
  • tony_t_tubbs
    ... Are you suggesting that the front-end development teams that are currently composed of essentially the UI/View developers (PC,Web folks), and the data
    Message 1 of 27 , Mar 5, 2009
      --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
      > Consider the following approach where the components have such
      > different technologies:
      > 1. Vertical teams consist of testers and the generalists (like myself)
      > who do like working in multiple technologies to make sure things
      > really work right,
      > 2. Horizontal (component) teams consist of specialists in each
      > specific technology,
      > 3. Vertical team members implement vertical user stories by
      > collaborating on specific tasks with appropriate horizontal team
      > members.
      >
      > This way the vertical stories are the scheduling and planning
      > mechanism to deliver the highest priority features within iteration
      > boundaries so as to reduce miscommunication and feedback latency
      > times.

      Are you suggesting that the front-end development teams that are currently composed of essentially the UI/View developers (PC,Web folks), and the data access folks (COBOL/Mainframe) are restructured so that all members of the team code in all layers? I know only a few people who can and like doing so. It seems the PC guys have a strong distaste for doing mainframe work and vise versa. You say "Horizontal (component) teams" above, but I'm not clear who you are referring to by that statement. This seems to be in contrast to the generalists you mention (which I'm thinking means codes in all layers). So, I am not understanding what happens to the UI and data access folks I just mentioned, as they are a tightly coupled team in that the data provided is intended for that UI being built, but they are not generalist nor component folks. Are they rerouted into other teams, or maybe forced (tactfully) into becoming generalists?. Now the infra teams I mentioned I see the component nature of their work (widgets, file uploaders, system loggers, etc.), but I don't see how that applies to the front end guys.

      If it is the Human Factors, Infra, and DB teams that are what you called the horizontal teams, then I understand what you've said and find your suggestions do make sense to me. If your comments include the idea of somehow the front end teams have horizontal folks on them, I'm confused.


      > This is not to say this approach does not have problems that would
      > have to be worked through. I know of no organization that uses such
      > an approach.

      You mean the approach you've suggested, right? Not the one I've described?
    • Steven Gordon
      I am not sure how to communicate my proposal more clearly. Do you have the assumption that software development work should always be done by a individual
      Message 2 of 27 , Mar 5, 2009
        I am not sure how to communicate my proposal more clearly.

        Do you have the assumption that software development work should
        always be done by a individual person working by themselves in their
        little cubicle?

        Is it not possible for two poeple to sit together and complete a
        software development subtask of a story, where:
        - the generalist has the understanding of the vertical story and how
        all the components should work together to accomplish that story, and
        - the specialist has the deep understanding of the particular
        component involved with the specific task and any consistency
        constraints for that component?

        http://www.google.com/search?q=pair+programming

        On Thu, Mar 5, 2009 at 10:03 AM, tony_t_tubbs <tony_t_tubbs@...> wrote:
        > --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...>
        > wrote:
        >> Consider the following approach where the components have such
        >> different technologies:
        >> 1. Vertical teams consist of testers and the generalists (like myself)
        >> who do like working in multiple technologies to make sure things
        >> really work right,
        >> 2. Horizontal (component) teams consist of specialists in each
        >> specific technology,
        >> 3. Vertical team members implement vertical user stories by
        >> collaborating on specific tasks with appropriate horizontal team
        >> members.
        >>
        >> This way the vertical stories are the scheduling and planning
        >> mechanism to deliver the highest priority features within iteration
        >> boundaries so as to reduce miscommunication and feedback latency
        >> times.
        >
        > Are you suggesting that the front-end development teams that are currently
        > composed of essentially the UI/View developers (PC,Web folks), and the data
        > access folks (COBOL/Mainframe) are restructured so that all members of the
        > team code in all layers? I know only a few people who can and like doing so.
        > It seems the PC guys have a strong distaste for doing mainframe work and
        > vise versa. You say "Horizontal (component) teams" above, but I'm not clear
        > who you are referring to by that statement. This seems to be in contrast to
        > the generalists you mention (which I'm thinking means codes in all layers).
        > So, I am not understanding what happens to the UI and data access folks I
        > just mentioned, as they are a tightly coupled team in that the data provided
        > is intended for that UI being built, but they are not generalist nor
        > component folks. Are they rerouted into other teams, or maybe forced
        > (tactfully) into becoming generalists?. Now the infra teams I mentioned I
        > see the component nature of their work (widgets, file uploaders, system
        > loggers, etc.), but I don't see how that applies to the front end guys.
        >
        > If it is the Human Factors, Infra, and DB teams that are what you called the
        > horizontal teams, then I understand what you've said and find your
        > suggestions do make sense to me. If your comments include the idea of
        > somehow the front end teams have horizontal folks on them, I'm confused.
        >
        >> This is not to say this approach does not have problems that would
        >> have to be worked through. I know of no organization that uses such
        >> an approach.
        >
        > You mean the approach you've suggested, right? Not the one I've described?
        >
      • tony_t_tubbs
        ... No ... Yes, that is possible, and is being done. This helps clarify for me. The use of specialist in this paragraph implies an OO or data access
        Message 3 of 27 , Mar 5, 2009
          --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
          >
          > I am not sure how to communicate my proposal more clearly.
          >
          > Do you have the assumption that software development work should
          > always be done by a individual person working by themselves in their
          > little cubicle?

          No

          > Is it not possible for two poeple to sit together and complete a
          > software development subtask of a story, where:
          > - the generalist has the understanding of the vertical story and how
          > all the components should work together to accomplish that story, and
          > - the specialist has the deep understanding of the particular
          > component involved with the specific task and any consistency
          > constraints for that component?

          Yes, that is possible, and is being done. This helps clarify for me. The use of 'specialist' in this paragraph implies an OO or data access specialist. I took the term in the previous post to refer to be Infrastructure, DBAs and Usability only. With this new understanding, it seems to me there are two different and distinct types of specialists. There are the in-team specialist (OO folks and Data folks, and I guess the generalists we don't really have now) who make up the team proper, are focused on a particular product (or three), and live the life of the project. Then there are the out-of-team specialists that have the focus of corporate consistency stuff, BUT instead of coding and throwing components over the wall, they are brought in as needed and pair with the application team (which implies they will need to pair with multiple teams). We have much room for improvement here, but we do have some level of pairing going on. Typically the data folks and the DBAs do some pairing, and the OO folks and us Infra widget makers do some work together. Granted, most of this is done as a sidebar to the product which results in something like a paired approach to throwing components over the wall, but is a start.

          Thanks again
        • Steven Gordon
          ... Glad you get my meaning now. The whole point is to try to find a way to avoid throwing stuff over the wall, because throwing stuff over the wall makes for:
          Message 4 of 27 , Mar 5, 2009
            On Thu, Mar 5, 2009 at 11:54 AM, tony_t_tubbs <tony_t_tubbs@...> wrote:
            > --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...>
            > wrote:
            >>
            >> I am not sure how to communicate my proposal more clearly.
            >>
            >> Do you have the assumption that software development work should
            >> always be done by a individual person working by themselves in their
            >> little cubicle?
            >
            > No
            >
            >> Is it not possible for two poeple to sit together and complete a
            >> software development subtask of a story, where:
            >> - the generalist has the understanding of the vertical story and how
            >> all the components should work together to accomplish that story, and
            >> - the specialist has the deep understanding of the particular
            >> component involved with the specific task and any consistency
            >> constraints for that component?
            >
            > Yes, that is possible, and is being done. This helps clarify for me. The use
            > of 'specialist' in this paragraph implies an OO or data access specialist. I
            > took the term in the previous post to refer to be Infrastructure, DBAs and
            > Usability only. With this new understanding, it seems to me there are two
            > different and distinct types of specialists. There are the in-team
            > specialist (OO folks and Data folks, and I guess the generalists we don't
            > really have now) who make up the team proper, are focused on a particular
            > product (or three), and live the life of the project. Then there are the
            > out-of-team specialists that have the focus of corporate consistency stuff,
            > BUT instead of coding and throwing components over the wall, they are
            > brought in as needed and pair with the application team (which implies they
            > will need to pair with multiple teams). We have much room for improvement
            > here, but we do have some level of pairing going on. Typically the data
            > folks and the DBAs do some pairing, and the OO folks and us Infra widget
            > makers do some work together. Granted, most of this is done as a sidebar to
            > the product which results in something like a paired approach to throwing
            > components over the wall, but is a start.
            >
            > Thanks again
            >

            Glad you get my meaning now.

            The whole point is to try to find a way to avoid throwing stuff over
            the wall, because throwing stuff over the wall makes for:
            - miscommunication that lead to incorrect work and eventual rework.
            - building more functionality than is actually needed,
            - long chains of feedback loops instead of time-bounded, direct feedback loops.

            The organizational resistance is usually based on a specialized
            division of labor being a more efficient use of resources. If it were
            not for the 3 problems above, this might well be true.

            Please, understand that I have never seen an organization implement
            this approach. I do think it could be made to work well.

            Steve
          • MasaKevin Maeda
            When component team members are idle, they could do one of the following depending on priorities: - refactoring of their component s code, - improvement of
            Message 5 of 27 , Mar 5, 2009
              "When component team members are idle, they could do one of the

              following depending on priorities:

              - refactoring of their component's code,

              - improvement of the performance of their component (without changing

              functionality) ,

              - help on any vertical stories outside of their component."

              "One solution is to get extremely formal, spec everything out in detail
              and coordinate a schedule of the work each component team does, but
              that is clearly not in the spirit of Agile. Short of that, if
              different teams are doing different parts of the work at different
              times, there will be different interpretations of what that work was
              supposed to do."

              I would add to the two statements above that I would encourage the team to do more testing before helping on vertical stories outside of their component; and if testing is done right then those tests result in more detailed documentation.

              My 2 cents,
               Masa K Maeda








              [Non-text portions of this message have been removed]
            • Tim Ottinger
              ... - Refactoring code - improvement of performance - help on other stories - improve test coverage ... aw, heck:
              Message 6 of 27 , Mar 6, 2009
                ----- Original Message ----
                > From: Steven Gordon <sgordonphd@...>
                > Yes, there may be no perfect solution. So, perhaps a hybrid model might work:
                >
                > 1. Have the stories driven vertically by verticals teams.
                > 2. Maintain additional small teams of infrastructural component
                > specialists (guardians).
                > 3. For each task of a vertically driven story that involves extending
                > or modifying a specific infrastructural component, a member of the
                > vertical team pairs with a member of the guardian team for that
                > component.
                >
                > When component team members are idle, they could do one of the
                > following depending on priorities:
                > - refactoring of their component's code,
                > - improvement of the performance of their component (without changing
                > functionality),
                > - help on any vertical stories outside of their component.
                >
                > Steve


                - Refactoring code
                - improvement of performance
                - help on other stories
                - improve test coverage

                ... aw, heck: http://agileinaflash.blogspot.com/2009/02/what-to-do-when-not-pairing.html


                Tim Ottinger
                http://agileinaflash.blogspot.com/
                http://agileotter.blogspot.com/
              Your message has been successfully submitted and would be delivered to recipients shortly.