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

Re: [XP] User-stories for components

Expand Messages
  • Kim Gräsman
    Torbjörn, On Wed, Mar 4, 2009 at 23:12, Torbjörn Gyllebring ... Right, this is precisely what I meant earlier, thanks for reaffirming :-) ... Good point,
    Message 1 of 27 , Mar 4, 2009
    • 0 Attachment
      Torbjörn,

      On Wed, Mar 4, 2009 at 23:12, Torbjörn Gyllebring
      <torbjorn.gyllebring@...> wrote:
      >
      > I should have been clearer with how I envisioned it based upon Kim's
      > initial post.
      > What I wanted to say was that I see no harm in having a component
      > "team" that is scattered between all clients of that component. Let's
      > call them specialists, guardians or evangelists their title really
      > doesn't matter for this discussion, although depending on your culture
      > you should probably choose carefully. As team members for their
      > vertical teams theese individuals are nothing but members with a
      > stronger inclination for that component, no different from Joe the UI
      > dude or Jane the bit-twiddling-sorcess. So Ivan the Infrastructure
      > guide probably likes that sort of work, will probably sign up for to
      > pair on most of them and as such will in that team be steering the
      > infrastructure work. Ivan also meets on an "as-needed" basis with the
      > other members of the infrastructure group to coordinate bigger changes
      > and get a feel for where the rest of the organization is moving, this
      > is in essence a Scrum of Scrums for a specific product, the shared
      > infrastructure, with some close by and really picky customers, all
      > other developers.

      Right, this is precisely what I meant earlier, thanks for reaffirming :-)

      > Yes if it turns into a dedicated "we do nothing but infrastructure
      > work all the time" clique I see a real danger but in the rosy scenario
      > above things should be fine. If big chunks of functioanlity needs to
      > be developed and can't be partioned, iterated, broken down and built
      > by the vertical teams then I guess some sort of rotation scheme could
      > be established to get create a temporary ad-hoc component-only team
      > for some duration.

      Good point, thanks!

      Oh, and thanks, Steven, for expounding further.

      - Kim
    • tony_t_tubbs
      ... I ve been wondering about these same things myself, and am enjoying this thread very much. My experience is also with large development organizations with
      Message 2 of 27 , Mar 5, 2009
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, Steven Gordon
        <sgordonphd@...> wrote:
        >
        > 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

        I've been wondering about these same things myself, and am enjoying this
        thread very much. My experience is also with large development
        organizations with many teams, and while reading various agile thoughts
        I often have the same 'in the real world' thoughts that start flames in
        these groups. If I may, I'd like to get down to some basic
        understanding of this whole vertical slice teams idea. I just can't
        seem to see how that could work. My vast ~15 years of experience fits
        this description:

        The organization develops multiple products all related to the same
        industry. For example financial related could include products dealing
        with stocks, bonds, mutual funds, retirement plans, etc or medical
        related could deal with billing, claims processing, insurance
        verification, verification of inseparability, etc. These products
        include not only the 1st order applications, but the printing and
        mailing systems, job queuing systems, etc. Some products produced have
        a narrow audience (HR department) and others are larger (call center
        phone reps). This big picture is then subdivided into teams on other
        continents dealing with international business, and teams in various
        states for US business. Each one of these divisions is responsible for
        multiple products that they develop. The clients use a mix of products,
        and this mix can and often does come from different teams. Though I've
        found it has always been a struggle, the organization as well as the
        clients want these products to easily talk to each other and look and
        feel the same / very similar. This has lead to some specialized teams,
        such as an infrastructure team and a human factors team, teams that are
        trying to ensure consistency across the organization but are not
        typically part of the front-end development teams. The actual
        development teams also have a division of labor between the desktop(PC,
        web, etc) and the SQL/COBOL guys who do their stuff on the mainframe.
        There's also a group everyone works with that controls the database and
        is there to ensure its integrity. It is my expreienc that this team is
        the heaviest bottle neck in that everyone else needs access to the data
        to build their apps. In some environments it is often not possible to
        schedule a meeting with them with less than a months notice. Human
        factors folks often come off to development types as if they are all
        theory, and have no practical experience. I've tended to agree, but am
        not sure that is exactly a fair representation. I am sure much of the
        problem is that their design tools are not the same tools developers
        implement with (Design in Visio and develop in HTML and JavaScript for
        example). The infrastructure team members often get loaned out to help
        at least jump start the front-end development, and we (yes I'm on the
        Infra side) have tried to make the components we produce work like
        internal open source so that we could pair with teams or teams could
        enhance things on there own so that we do not become the bottle-neck,
        but we have not realized this. Most teams still wait on us (they have
        other tasks they could be working on), and, in my probably biased
        opinion, use it as something to point fingers at.

        So, my questions:
        - Does this vertical slice idea mean developers must know both the PC
        languages/tools as well as the mainframe? Have you had success finding
        people that want to do both, or are at least fine with doing so? My
        experience is that there are folks on each side of that that have no
        desire to learn the other.

        - How would you restructure to get the vertical slicing achieved, or
        even just to start it on the path to agile development? It seems
        natural that a separate Infra, DB and Usability teams have emerged out
        of this, I need help seeing how that could become different.

        - If you were to reverse things as it seems to be the implication from
        this tread, and each team were to do slices themselves, including the
        components they use, what would be the technique to ensure the cross
        application communication, similar look and feel, and all the DB science
        (fast indexing, normalization, etc) are achieved? (Basically, the
        desire is that all apps coming from the organization look and feel as if
        they came from the same organization.)










        [Non-text portions of this message have been removed]
      • Steven Gordon
        ... Tony, This is a problem. Consider the following approach where the components have such different technologies: 1. Vertical teams consist of testers and
        Message 3 of 27 , Mar 5, 2009
        • 0 Attachment
          On Thu, Mar 5, 2009 at 8:15 AM, tony_t_tubbs <tony_t_tubbs@...> wrote:
          >
          >
          > --- In extremeprogramming@yahoogroups.com, Steven Gordon
          > <sgordonphd@...> wrote:
          >>
          >> 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
          >

          >
          > So, my questions:
          > - Does this vertical slice idea mean developers must know both the PC
          > languages/tools as well as the mainframe? Have you had success finding
          > people that want to do both, or are at least fine with doing so? My
          > experience is that there are folks on each side of that that have no
          > desire to learn the other.

          Tony,

          This is a problem.

          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.

          >
          > - How would you restructure to get the vertical slicing achieved, or
          > even just to start it on the path to agile development? It seems
          > natural that a separate Infra, DB and Usability teams have emerged out
          > of this, I need help seeing how that could become different.

          People on these teams would collaborate on vertical stories as
          coordinated by the vertical teams.

          >
          > - If you were to reverse things as it seems to be the implication from
          > this tread, and each team were to do slices themselves, including the
          > components they use, what would be the technique to ensure the cross
          > application communication, similar look and feel, and all the DB science
          > (fast indexing, normalization, etc) are achieved? (Basically, the
          > desire is that all apps coming from the organization look and feel as if
          > they came from the same organization.)
          >

          The component specialists collaborating on the vertical stories should
          be responsible for knowing about these constraints, ensuring they are
          met by any changes or new development they are involved in, and
          perhaps scheduling intense optimization work to be done when no
          vertical team is asking for their time.

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

          The key point is that we do not just hand off work to the specialists,
          but have generalists who are responsible for delivering working
          vertical slices actively collaborate on each piece with specialists.
          After the stories work acceptably with sufficient automated tests to
          make sure they continue to do so, the specialists can refine the code
          for performance and consistency when that is their highest priority
          tasks.

          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.

          Steve
        • 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 4 of 27 , Mar 5, 2009
          • 0 Attachment
            --- 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 5 of 27 , Mar 5, 2009
            • 0 Attachment
              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 6 of 27 , Mar 5, 2009
              • 0 Attachment
                --- 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 7 of 27 , Mar 5, 2009
                • 0 Attachment
                  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 8 of 27 , Mar 5, 2009
                  • 0 Attachment
                    "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 9 of 27 , Mar 6, 2009
                    • 0 Attachment
                      ----- 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.