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

User-stories for components

Expand Messages
  • Rhydian Thomas
    When your developing an application you can describe its features in terms of users performing actions to achieve some business goal, with a user-story ( As as
    Message 1 of 27 , Mar 4, 2009
    • 0 Attachment
      When your developing an application you can describe its features in
      terms of users performing actions to achieve some business goal, with
      a user-story ("As as X, I want Y, so that Z", for instance). I've yet
      to see this work for components though. Do you use user-stories to
      capture the requirements of a component? For example - I'm working on
      component part of a reporting system; it's a batch process which, on a
      defined schedule, extracts records from a database, performs some
      calculations and then posts the results to a web service. I've been
      wondering how I might capture the requirements of such a component and
      whether it makes sense to do so using stories?
    • Adrian Howard
      ... As a (whoever uses the reports) I need to (view such-and-such report on a web page) so I can (why they need the report) ? Adrian
      Message 2 of 27 , Mar 4, 2009
      • 0 Attachment
        On 4 Mar 2009, at 10:43, Rhydian Thomas wrote:

        > When your developing an application you can describe its features in
        > terms of users performing actions to achieve some business goal, with
        > a user-story ("As as X, I want Y, so that Z", for instance). I've yet
        > to see this work for components though. Do you use user-stories to
        > capture the requirements of a component? For example - I'm working on
        > component part of a reporting system; it's a batch process which, on a
        > defined schedule, extracts records from a database, performs some
        > calculations and then posts the results to a web service. I've been
        > wondering how I might capture the requirements of such a component and
        > whether it makes sense to do so using stories?

        As a (whoever uses the reports) I need to (view such-and-such report
        on a web page) so I can (why they need the report) ?

        Adrian
      • Mayank Gupta
        Certainly it makes sense to have such stories. A user story for component: I consider it as a theme story and this should be broken down (depends on how big
        Message 3 of 27 , Mar 4, 2009
        • 0 Attachment
          Certainly it makes sense to have such stories.

          A user story for component: I consider it as a theme story and this
          should be broken down (depends on how big this theme story is) into
          smaller stories.



          Remember, each story should have a role, the capacity (the feature) and
          the value associated with it.



          Thanks,

          Mayank

          ________________________________

          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Rhydian Thomas
          Sent: Wednesday, March 04, 2009 4:14 PM
          To: extremeprogramming@yahoogroups.com
          Subject: [XP] User-stories for components



          When your developing an application you can describe its features in
          terms of users performing actions to achieve some business goal, with
          a user-story ("As as X, I want Y, so that Z", for instance). I've yet
          to see this work for components though. Do you use user-stories to
          capture the requirements of a component? For example - I'm working on
          component part of a reporting system; it's a batch process which, on a
          defined schedule, extracts records from a database, performs some
          calculations and then posts the results to a web service. I've been
          wondering how I might capture the requirements of such a component and
          whether it makes sense to do so using stories?





          [Non-text portions of this message have been removed]
        • amr_samadisy
          ... I m not so sure it makes sense to me. I believe the original poster said that it goes to a web service. Usually a web service isn t consumed directly by
          Message 4 of 27 , Mar 4, 2009
          • 0 Attachment
            >
            > Certainly it makes sense to have such stories.
            >

            I'm not so sure it makes sense to me. I believe the original poster
            said that it goes to a web service. Usually a web service isn't
            consumed directly by a user. So you are not really building something
            end-to-end.

            I would ask a complementary question to the group:

            Does it always make sense to build things end-to-end in thin slices? If
            not, then when? If so, then I believe the answer to the question is
            that you shouldn't be building stand alone components.

            My 2 piasters - Amr
          • Steven Gordon
            ... A strong point in favor of Adrian s suggestion is that all the extensions to all the components required to deliver this value to users is accomplished
            Message 5 of 27 , Mar 4, 2009
            • 0 Attachment
              On Wed, Mar 4, 2009 at 4:59 AM, Adrian Howard <adrianh@...> wrote:
              >
              > On 4 Mar 2009, at 10:43, Rhydian Thomas wrote:
              >
              >> When your developing an application you can describe its features in
              >> terms of users performing actions to achieve some business goal, with
              >> a user-story ("As as X, I want Y, so that Z", for instance). I've yet
              >> to see this work for components though. Do you use user-stories to
              >> capture the requirements of a component? For example - I'm working on
              >> component part of a reporting system; it's a batch process which, on a
              >> defined schedule, extracts records from a database, performs some
              >> calculations and then posts the results to a web service. I've been
              >> wondering how I might capture the requirements of such a component and
              >> whether it makes sense to do so using stories?
              >
              > As a (whoever uses the reports) I need to (view such-and-such report
              > on a web page) so I can (why they need the report) ?
              >
              > Adrian

              A strong point in favor of Adrian's suggestion is that all the
              extensions to all the components required to deliver this value to
              users is accomplished under the same umbrella.

              No risk of miscommunication by handing specifications off between
              teams that each extend the component that they "own" at different
              points in time. Having one component being extended without
              delivering any value until the other components are extended not only
              wastes work and creates extra complexity, but also increases the delay
              in getting and responding to customer feedback.

              For example:
              -Team W extends the reporting web service in the way that they
              understand the requirements,
              - 2 months later team U implements the code that uses the web service
              to provide the functionality to the end user,
              - A week later, the customer or end users say that this is not what
              they wanted (because of bugs or misunderstandings or
              miscommunications),
              It might be 3 months later that team W finally deals with these
              issues. 3 months latency time on feedback loops is definitely not
              agile.

              A single team should be understanding, testing, implementing and
              delivering each end-to-end user story no matter how many components
              the story touches. Each component should be coded clearly enough and
              have sufficient unit tests that anybody on any team should be able to
              extend any component they need to.

              Siloing the teams horizontally along component lines instead of
              vertically along functionality lines is a process smell. It may seem
              inefficient for developers to not specialize on a particular
              component, but the communication costs and loss of direct feedback
              actually creates greater inefficiencies.

              Steven Gordon
            • Charlie Poole
              Hi Amr, ... Surely you knew the answer would be It depends. :-) I agree that it s generally a bad idea to build components in isolation from the rest of the
              Message 6 of 27 , Mar 4, 2009
              • 0 Attachment
                Hi Amr,

                > I'm not so sure it makes sense to me. I believe the original
                > poster said that it goes to a web service. Usually a web
                > service isn't consumed directly by a user. So you are not
                > really building something end-to-end.
                >
                > I would ask a complementary question to the group:
                >
                > Does it always make sense to build things end-to-end in thin
                > slices? If not, then when? If so, then I believe the answer
                > to the question is that you shouldn't be building stand alone
                > components.
                >
                > My 2 piasters - Amr

                Surely you knew the answer would be "It depends." :-)

                I agree that it's generally a bad idea to build components
                in isolation from the rest of the application or product -
                and especially in isolation from the rest of the team.

                But sometimes, the component may be the entire product and
                there is little choice. The OP didn't make it clear where
                the boundaries of his project lie, but I doubt that the
                loading of the database is the entire project.

                That leaves two possibilities: the project is /only/ the
                development of a web service or it's part of some larger
                whole. If the latter applies, I'd use a story much like
                the one suggested earlier.

                Suppose this project is limited to creating the web service
                and other projects will be using it. I would not set things
                up this way given a choice, but I have seen it quite often.
                In that case, one may be tempted to treat the client
                software as the "user." I'd avoid that because such an abstrct
                user can't answer questions. Rather, I'd treat the programmer
                of the client app as the user: "As a client app programmer... "

                In that case, I may actually be able to find such people and
                ask them questions. Better though if the web service is part
                of the same project with one or two consumers and all of them
                can then be developed in parallel.

                Charlie
              • Kim Gräsman
                Hi Steven, ... I agree wholeheartedly with the principle, and I think vertical teams is the way to go. But I ve seen some friction in a larger multi-project
                Message 7 of 27 , Mar 4, 2009
                • 0 Attachment
                  Hi Steven,

                  On Wed, Mar 4, 2009 at 16:25, Steven Gordon <sgordonphd@...> wrote:
                  >
                  > A single team should be understanding, testing, implementing and
                  > delivering each end-to-end user story no matter how many components
                  > the story touches.  Each component should be coded clearly enough and
                  > have sufficient unit tests that anybody on any team should be able to
                  > extend any component they need to.
                  >
                  > Siloing the teams horizontally along component lines instead of
                  > vertically along functionality lines is a process smell.  It may seem
                  > inefficient for developers to not specialize on a particular
                  > component, but the communication costs and loss of direct feedback
                  > actually creates greater inefficiencies.

                  I agree wholeheartedly with the principle, and I think vertical teams
                  is the way to go.

                  But I've seen some friction in a larger multi-project lately (15+
                  projects x 5-10 developers) where vertical developments add features
                  to infrastructure code as they need it, and the result is pretty
                  shaky.

                  Everybody is pretty frustrated with the infrastructure being a moving
                  target, and there's chatting by the water coolers wanting
                  "responsibility" and "clear component ownership". This worries me, but
                  I can see that the current way of doing it is sub-ideal.

                  Do you have any tips for coordinating changes among such a large developer base?

                  One of my hypotheses is setting up an infrastructure team (heresy, I
                  know) and then disperse it among the feature projects with 1-2
                  infrastructure devs per feature project, so that they can feel the
                  application needs, solve them in-place and/or feed information back to
                  the infrastructure group as often as possible. Thoughts?

                  Thanks,
                  - Kim
                • Torbjörn Gyllebring
                  Can someone please explain where the notion that actually having a infrastructure, database or other team would somehow kill cross-functional teamage? Yes,
                  Message 8 of 27 , Mar 4, 2009
                  • 0 Attachment
                    Can someone please explain where the notion that actually having a
                    infrastructure, database or other team would somehow kill
                    cross-functional teamage?

                    Yes, everyone should be encouraged to contribute to the
                    infrastructure, database design and other things but I've never found
                    any reason that should exclude coordination and vision for those
                    components.

                    If you call those individuals infrastructure evangelists, and their
                    meeting "Scrum of Scrums" would that still be hersesy?

                    On Wed, Mar 4, 2009 at 9:09 PM, Kim Gräsman <kim.grasman@...> wrote:
                    > Hi Steven,
                    >
                    > On Wed, Mar 4, 2009 at 16:25, Steven Gordon <sgordonphd@...> wrote:
                    >>
                    >> A single team should be understanding, testing, implementing and
                    >> delivering each end-to-end user story no matter how many components
                    >> the story touches.  Each component should be coded clearly enough and
                    >> have sufficient unit tests that anybody on any team should be able to
                    >> extend any component they need to.
                    >>
                    >> Siloing the teams horizontally along component lines instead of
                    >> vertically along functionality lines is a process smell.  It may seem
                    >> inefficient for developers to not specialize on a particular
                    >> component, but the communication costs and loss of direct feedback
                    >> actually creates greater inefficiencies.
                    >
                    > I agree wholeheartedly with the principle, and I think vertical teams
                    > is the way to go.
                    >
                    > But I've seen some friction in a larger multi-project lately (15+
                    > projects x 5-10 developers) where vertical developments add features
                    > to infrastructure code as they need it, and the result is pretty
                    > shaky.
                    >
                    > Everybody is pretty frustrated with the infrastructure being a moving
                    > target, and there's chatting by the water coolers wanting
                    > "responsibility" and "clear component ownership". This worries me, but
                    > I can see that the current way of doing it is sub-ideal.
                    >
                    > Do you have any tips for coordinating changes among such a large developer
                    > base?
                    >
                    > One of my hypotheses is setting up an infrastructure team (heresy, I
                    > know) and then disperse it among the feature projects with 1-2
                    > infrastructure devs per feature project, so that they can feel the
                    > application needs, solve them in-place and/or feed information back to
                    > the infrastructure group as often as possible. Thoughts?
                    >
                    > Thanks,
                    > - Kim
                    >
                    >
                  • Kim Gräsman
                    Hi Torbjörn, On Wed, Mar 4, 2009 at 21:33, Torbjörn Gyllebring ... The heresy comment was tongue-in-cheek. Sorry for not making that clearer... It s
                    Message 9 of 27 , Mar 4, 2009
                    • 0 Attachment
                      Hi Torbjörn,

                      On Wed, Mar 4, 2009 at 21:33, Torbjörn Gyllebring
                      <torbjorn.gyllebring@...> wrote:
                      > Can someone please explain where the notion that actually having a
                      > infrastructure, database or other team would somehow kill
                      > cross-functional teamage?
                      >
                      > Yes, everyone should be encouraged to contribute to the
                      > infrastructure, database design and other things but I've never found
                      > any reason that should exclude coordination and vision for those
                      > components.
                      >
                      > If you call those individuals infrastructure evangelists, and their
                      > meeting "Scrum of Scrums" would that still be hersesy?

                      The 'heresy' comment was tongue-in-cheek. Sorry for not making that clearer...

                      It's interesting that you bring up scrum-of-scrums -- I think it would
                      play especially well with a team scattered across other feature teams.

                      I think there's a clear risk of a specialized infrastructure team
                      becoming a bottleneck, as they probably won't have the bandwidth to
                      collect all needs and implement them at the same pace feature teams
                      deliver. Also, it risks building a bunch of specialists who are stuck
                      in their role and mustn't leave for fear of irreplaceability.

                      That said, there probably are ways around these problems. Rotation, perhaps?

                      - Kim
                    • Steven Gordon
                      ... 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
                      Message 10 of 27 , Mar 4, 2009
                      • 0 Attachment
                        On Wed, Mar 4, 2009 at 1:09 PM, Kim Gräsman <kim.grasman@...> wrote:
                        > Hi Steven,
                        >
                        > On Wed, Mar 4, 2009 at 16:25, Steven Gordon <sgordonphd@...> wrote:
                        >>
                        >> A single team should be understanding, testing, implementing and
                        >> delivering each end-to-end user story no matter how many components
                        >> the story touches.  Each component should be coded clearly enough and
                        >> have sufficient unit tests that anybody on any team should be able to
                        >> extend any component they need to.
                        >>
                        >> Siloing the teams horizontally along component lines instead of
                        >> vertically along functionality lines is a process smell.  It may seem
                        >> inefficient for developers to not specialize on a particular
                        >> component, but the communication costs and loss of direct feedback
                        >> actually creates greater inefficiencies.
                        >
                        > I agree wholeheartedly with the principle, and I think vertical teams
                        > is the way to go.
                        >
                        > But I've seen some friction in a larger multi-project lately (15+
                        > projects x 5-10 developers) where vertical developments add features
                        > to infrastructure code as they need it, and the result is pretty
                        > shaky.
                        >
                        > Everybody is pretty frustrated with the infrastructure being a moving
                        > target, and there's chatting by the water coolers wanting
                        > "responsibility" and "clear component ownership". This worries me, but
                        > I can see that the current way of doing it is sub-ideal.
                        >
                        > Do you have any tips for coordinating changes among such a large developer
                        > base?
                        >
                        > One of my hypotheses is setting up an infrastructure team (heresy, I
                        > know) and then disperse it among the feature projects with 1-2
                        > infrastructure devs per feature project, so that they can feel the
                        > application needs, solve them in-place and/or feed information back to
                        > the infrastructure group as often as possible. Thoughts?
                        >
                        > Thanks,
                        > - Kim

                        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
                      • Steven Gordon
                        On Wed, Mar 4, 2009 at 1:33 PM, Torbjörn Gyllebring ... The problem is the extra layers of communication make for different interpretations of what needs to
                        Message 11 of 27 , Mar 4, 2009
                        • 0 Attachment
                          On Wed, Mar 4, 2009 at 1:33 PM, Torbjörn Gyllebring
                          <torbjorn.gyllebring@...> wrote:
                          > Can someone please explain where the notion that actually having a
                          > infrastructure, database or other team would somehow kill
                          > cross-functional teamage?
                          >
                          > Yes, everyone should be encouraged to contribute to the
                          > infrastructure, database design and other things but I've never found
                          > any reason that should exclude coordination and vision for those
                          > components.
                          >
                          > If you call those individuals infrastructure evangelists, and their
                          > meeting "Scrum of Scrums" would that still be hersesy?
                          >

                          The problem is the extra layers of communication make for different
                          interpretations of what needs to be done in each component and that
                          cascading dependencies will often push out the latency time between
                          when work first starts on a component and when working software is
                          available for the customer to accept or reject.

                          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.
                        • Steven Gordon
                          ... Many places I have seen component teams, they fear getting behind so much that they start including anticipated future functionality in everything they do.
                          Message 12 of 27 , Mar 4, 2009
                          • 0 Attachment
                            On Wed, Mar 4, 2009 at 2:07 PM, Kim Gräsman <kim.grasman@...> wrote:
                            > Hi Torbjörn,
                            >
                            > On Wed, Mar 4, 2009 at 21:33, Torbjörn Gyllebring
                            > <torbjorn.gyllebring@...> wrote:
                            >> Can someone please explain where the notion that actually having a
                            >> infrastructure, database or other team would somehow kill
                            >> cross-functional teamage?
                            >>
                            >> Yes, everyone should be encouraged to contribute to the
                            >> infrastructure, database design and other things but I've never found
                            >> any reason that should exclude coordination and vision for those
                            >> components.
                            >>
                            >> If you call those individuals infrastructure evangelists, and their
                            >> meeting "Scrum of Scrums" would that still be hersesy?
                            >
                            > The 'heresy' comment was tongue-in-cheek. Sorry for not making that
                            > clearer...
                            >
                            > It's interesting that you bring up scrum-of-scrums -- I think it would
                            > play especially well with a team scattered across other feature teams.
                            >
                            > I think there's a clear risk of a specialized infrastructure team
                            > becoming a bottleneck, as they probably won't have the bandwidth to
                            > collect all needs and implement them at the same pace feature teams
                            > deliver.

                            Many places I have seen component teams, they fear getting behind so
                            much that they start including anticipated future functionality in
                            everything they do. In the best case, there is just a bunch of YAGNI;
                            in the worst case. it turns into churning out widgets and telling the
                            application teams that the widgets provide everything they should ever
                            need to complete their stories.

                            A common factor for this worst case is in the context of product
                            lines, where the component teams often take on the mission of
                            facilitating interoperability and product consistency by mandating
                            what widgets the application teams will use and then proceed to build
                            them whether or not they support the stories the application teams are
                            currently working on.

                            > Also, it risks building a bunch of specialists who are stuck
                            > in their role and mustn't leave for fear of irreplaceability.
                            >
                            > That said, there probably are ways around these problems. Rotation, perhaps?
                            >
                            > - Kim
                            \
                          • Rhydian Thomas
                            ... That sounds like the model being used at the company I worked for when developing the example component I mentioned in my original post - product lines,
                            Message 13 of 27 , Mar 4, 2009
                            • 0 Attachment
                              On 05/03/2009, at 8:38 AM, Steven Gordon wrote:
                              > Many places I have seen component teams, they fear getting behind so
                              > much that they start including anticipated future functionality in
                              > everything they do. In the best case, there is just a bunch of YAGNI;
                              > in the worst case. it turns into churning out widgets and telling the
                              > application teams that the widgets provide everything they should ever
                              > need to complete their stories.
                              >
                              > A common factor for this worst case is in the context of product
                              > lines, where the component teams often take on the mission of
                              > facilitating interoperability and product consistency by mandating
                              > what widgets the application teams will use and then proceed to build
                              > them whether or not they support the stories the application teams are
                              > currently working on.
                              >

                              That sounds like the model being used at the company I worked for when
                              developing the example component I mentioned in my original post -
                              product lines, goal to build 'flexible', configurable, reusable
                              components that could be pieced together and configured when another
                              customer came along. So perhaps I was struggling to see how user-
                              stories could be used as I was attempting to use an agile practice in
                              a non-agile environment? Can agile work in such an environment?
                            • Torbjörn Gyllebring
                              Hi Kim and Steven, 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
                              Message 14 of 27 , Mar 4, 2009
                              • 0 Attachment
                                Hi Kim and Steven,

                                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.

                                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.


                                On Wed, Mar 4, 2009 at 10:07 PM, Kim Gräsman <kim.grasman@...> wrote:
                                > Hi Torbjörn,
                                >
                                > On Wed, Mar 4, 2009 at 21:33, Torbjörn Gyllebring
                                > <torbjorn.gyllebring@...> wrote:
                                >> Can someone please explain where the notion that actually having a
                                >> infrastructure, database or other team would somehow kill
                                >> cross-functional teamage?
                                >>
                                >> Yes, everyone should be encouraged to contribute to the
                                >> infrastructure, database design and other things but I've never found
                                >> any reason that should exclude coordination and vision for those
                                >> components.
                                >>
                                >> If you call those individuals infrastructure evangelists, and their
                                >> meeting "Scrum of Scrums" would that still be hersesy?
                                >
                                > The 'heresy' comment was tongue-in-cheek. Sorry for not making that
                                > clearer...
                                >
                                > It's interesting that you bring up scrum-of-scrums -- I think it would
                                > play especially well with a team scattered across other feature teams.
                                >
                                > I think there's a clear risk of a specialized infrastructure team
                                > becoming a bottleneck, as they probably won't have the bandwidth to
                                > collect all needs and implement them at the same pace feature teams
                                > deliver. Also, it risks building a bunch of specialists who are stuck
                                > in their role and mustn't leave for fear of irreplaceability.
                                >
                                > That said, there probably are ways around these problems. Rotation, perhaps?
                                >
                                > - Kim
                                >
                                >
                              • Steven Gordon
                                ... Do you mean user stories in an otherwise non-agile approach? I am not sure if that can accomplish much. Do you mean every team iteratively delivers on a
                                Message 15 of 27 , Mar 4, 2009
                                • 0 Attachment
                                  On Wed, Mar 4, 2009 at 2:54 PM, Rhydian Thomas <rhydthom@...> wrote:
                                  >
                                  > On 05/03/2009, at 8:38 AM, Steven Gordon wrote:
                                  >> Many places I have seen component teams, they fear getting behind so
                                  >> much that they start including anticipated future functionality in
                                  >> everything they do. In the best case, there is just a bunch of YAGNI;
                                  >> in the worst case. it turns into churning out widgets and telling the
                                  >> application teams that the widgets provide everything they should ever
                                  >> need to complete their stories.
                                  >>
                                  >> A common factor for this worst case is in the context of product
                                  >> lines, where the component teams often take on the mission of
                                  >> facilitating interoperability and product consistency by mandating
                                  >> what widgets the application teams will use and then proceed to build
                                  >> them whether or not they support the stories the application teams are
                                  >> currently working on.
                                  >>
                                  >
                                  > That sounds like the model being used at the company I worked for when
                                  > developing the example component I mentioned in my original post -
                                  > product lines, goal to build 'flexible', configurable, reusable
                                  > components that could be pieced together and configured when another
                                  > customer came along. So perhaps I was struggling to see how user-
                                  > stories could be used as I was attempting to use an agile practice in
                                  > a non-agile environment? Can agile work in such an environment?
                                  >

                                  Do you mean user stories in an otherwise non-agile approach? I am not
                                  sure if that can accomplish much.

                                  Do you mean every team iteratively delivers on a backlog, but the
                                  backlog for the architectural teams are the widgets that would seem to
                                  be generally useful for the user stories on the application teams'
                                  backlogs? It can work, just not as well as if the architectural teams
                                  directly collaborate on the application-level user stories. I would
                                  generally expect more bloat, more architecture that goes unused, more
                                  code complexity, a higher cost of maintenance, a higher cost of change
                                  and a slower responsiveness to change than there should have to be.

                                  Engineer utilization would likely be higher under this approach. But,
                                  is the goal to keep the engineers busy or minimize how long it takes
                                  to deliver features? This is a fallacy that project management falls
                                  into because a Gant Chart tells you that maximizing utilization will
                                  decrease how long it takes to deliver the whole project.

                                  Is the goal of a server farm to maximize utilization of the servers or
                                  minimize transaction times? Is the goal of building a new freeway to
                                  maximize the number of cars that use it or minimize how long it takes
                                  people to go from point A to point B? For some reason, people see the
                                  fallacy of maximizing utilization much better with inanimate objects
                                  than with people.

                                  Steve
                                • Rhydian Thomas
                                  Hi Steve, In a nutshell ... the product was a framework which the customer team would take and build a UI on top of and implement various integration points
                                  Message 16 of 27 , Mar 4, 2009
                                  • 0 Attachment
                                    Hi Steve,

                                    In a nutshell ... the 'product' was a framework which the customer team would take and build a UI on top of and implement various integration points (e.g. with billing servers, content management systems, etc) ... So our aim was to develop and maintain the various components of this framework such that it could accomodate the requirements of the customer team.

                                    We used Scrum, development was incremental and iterative, in each iteration we would tackle bugs, feature enhancements, etc. which centred around different component parts.

                                    In that context, I wonder whether user-stories could have been used as a requirements tool. Can you use the same concepts of a short narrative to capture the feature, discussion with business owners to ellaborate on detail, acceptance criteria to know when we're done and automate them ... when there is no UI, no real customer.



                                    --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
                                    >
                                    > On Wed, Mar 4, 2009 at 2:54 PM, Rhydian Thomas <rhydthom@...> wrote:
                                    > >
                                    > > On 05/03/2009, at 8:38 AM, Steven Gordon wrote:
                                    > >> Many places I have seen component teams, they fear getting behind so
                                    > >> much that they start including anticipated future functionality in
                                    > >> everything they do. In the best case, there is just a bunch of YAGNI;
                                    > >> in the worst case. it turns into churning out widgets and telling the
                                    > >> application teams that the widgets provide everything they should ever
                                    > >> need to complete their stories.
                                    > >>
                                    > >> A common factor for this worst case is in the context of product
                                    > >> lines, where the component teams often take on the mission of
                                    > >> facilitating interoperability and product consistency by mandating
                                    > >> what widgets the application teams will use and then proceed to build
                                    > >> them whether or not they support the stories the application teams are
                                    > >> currently working on.
                                    > >>
                                    > >
                                    > > That sounds like the model being used at the company I worked for when
                                    > > developing the example component I mentioned in my original post -
                                    > > product lines, goal to build 'flexible', configurable, reusable
                                    > > components that could be pieced together and configured when another
                                    > > customer came along. So perhaps I was struggling to see how user-
                                    > > stories could be used as I was attempting to use an agile practice in
                                    > > a non-agile environment? Can agile work in such an environment?
                                    > >
                                    >
                                    > Do you mean user stories in an otherwise non-agile approach? I am not
                                    > sure if that can accomplish much.
                                    >
                                    > Do you mean every team iteratively delivers on a backlog, but the
                                    > backlog for the architectural teams are the widgets that would seem to
                                    > be generally useful for the user stories on the application teams'
                                    > backlogs? It can work, just not as well as if the architectural teams
                                    > directly collaborate on the application-level user stories. I would
                                    > generally expect more bloat, more architecture that goes unused, more
                                    > code complexity, a higher cost of maintenance, a higher cost of change
                                    > and a slower responsiveness to change than there should have to be.
                                    >
                                    > Engineer utilization would likely be higher under this approach. But,
                                    > is the goal to keep the engineers busy or minimize how long it takes
                                    > to deliver features? This is a fallacy that project management falls
                                    > into because a Gant Chart tells you that maximizing utilization will
                                    > decrease how long it takes to deliver the whole project.
                                    >
                                    > Is the goal of a server farm to maximize utilization of the servers or
                                    > minimize transaction times? Is the goal of building a new freeway to
                                    > maximize the number of cars that use it or minimize how long it takes
                                    > people to go from point A to point B? For some reason, people see the
                                    > fallacy of maximizing utilization much better with inanimate objects
                                    > than with people.
                                    >
                                    > Steve
                                    >
                                  • Steven Gordon
                                    ... The product is a framework and the real customers are development teams in different organizations around the world that would be using the framework to
                                    Message 17 of 27 , Mar 4, 2009
                                    • 0 Attachment
                                      On Wed, Mar 4, 2009 at 6:21 PM, Rhydian Thomas <rhydthom@...> wrote:
                                      > Hi Steve,
                                      >
                                      > In a nutshell ... the 'product' was a framework which the customer team
                                      > would take and build a UI on top of and implement various integration points
                                      > (e.g. with billing servers, content management systems, etc) ... So our aim
                                      > was to develop and maintain the various components of this framework such
                                      > that it could accomodate the requirements of the customer team.
                                      >
                                      > We used Scrum, development was incremental and iterative, in each iteration
                                      > we would tackle bugs, feature enhancements, etc. which centred around
                                      > different component parts.
                                      >
                                      > In that context, I wonder whether user-stories could have been used as a
                                      > requirements tool. Can you use the same concepts of a short narrative to
                                      > capture the feature, discussion with business owners to ellaborate on
                                      > detail, acceptance criteria to know when we're done and automate them ...
                                      > when there is no UI, no real customer.
                                      >

                                      The product is a framework and the real customers are development
                                      teams in different organizations around the world that would be using
                                      the framework to build whatever their customer's need. Right?

                                      To do agile, you would still need a "customer" (i.e., product owner in
                                      Scrum) to create user stories that adequately represent what the
                                      actual customers need and prioritize them. I am sure it is possible
                                      to write appropriate stories.

                                      You also need some way for that customer to determine that those
                                      stories have been implemented acceptably. That would seem to be
                                      difficult without actually utilizing the functionality in the way you
                                      would expect a real customer to utilize it.

                                      I would strongly suggest that there be a team that builds a typical
                                      customer application using the framework product to not only verify
                                      that the framework really does what it is supposed to, but also to
                                      provide customers with the code of a nice working example of how to
                                      use the framework (like the Pet Store app that came along with early
                                      releases of J2EE - does it still come with it?). The more coherent,
                                      automated test code that comes with the framework and the sample app,
                                      the better for your customers.

                                      Steve
                                    • jmilunsky
                                      It really doesn t matter whether you re delivering UI to the customer or not. User stories are still the way to go to manage the requirements process. You
                                      Message 18 of 27 , Mar 4, 2009
                                      • 0 Attachment
                                        It really doesn't matter whether you're delivering UI to the customer or not. User stories are still the way to go to manage the requirements process. You should check out Mike Cohn's site. He has a lot of information about Epics, themes, and stories and how to break them down. His site is mountaingoatsoftware.com

                                        Hope this helps
                                        Jack
                                        www.agilebuddy.com
                                        blog.agilebuddy.com

                                        --- In extremeprogramming@yahoogroups.com, "Rhydian Thomas" <rhydthom@...> wrote:
                                        >
                                        > Hi Steve,
                                        >
                                        > In a nutshell ... the 'product' was a framework which the customer team would take and build a UI on top of and implement various integration points (e.g. with billing servers, content management systems, etc) ... So our aim was to develop and maintain the various components of this framework such that it could accomodate the requirements of the customer team.
                                        >
                                        > We used Scrum, development was incremental and iterative, in each iteration we would tackle bugs, feature enhancements, etc. which centred around different component parts.
                                        >
                                        > In that context, I wonder whether user-stories could have been used as a requirements tool. Can you use the same concepts of a short narrative to capture the feature, discussion with business owners to ellaborate on detail, acceptance criteria to know when we're done and automate them ... when there is no UI, no real customer.
                                        >
                                        >
                                        >
                                        > --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@> wrote:
                                        > >
                                        > > On Wed, Mar 4, 2009 at 2:54 PM, Rhydian Thomas <rhydthom@> wrote:
                                        > > >
                                        > > > On 05/03/2009, at 8:38 AM, Steven Gordon wrote:
                                        > > >> Many places I have seen component teams, they fear getting behind so
                                        > > >> much that they start including anticipated future functionality in
                                        > > >> everything they do. In the best case, there is just a bunch of YAGNI;
                                        > > >> in the worst case. it turns into churning out widgets and telling the
                                        > > >> application teams that the widgets provide everything they should ever
                                        > > >> need to complete their stories.
                                        > > >>
                                        > > >> A common factor for this worst case is in the context of product
                                        > > >> lines, where the component teams often take on the mission of
                                        > > >> facilitating interoperability and product consistency by mandating
                                        > > >> what widgets the application teams will use and then proceed to build
                                        > > >> them whether or not they support the stories the application teams are
                                        > > >> currently working on.
                                        > > >>
                                        > > >
                                        > > > That sounds like the model being used at the company I worked for when
                                        > > > developing the example component I mentioned in my original post -
                                        > > > product lines, goal to build 'flexible', configurable, reusable
                                        > > > components that could be pieced together and configured when another
                                        > > > customer came along. So perhaps I was struggling to see how user-
                                        > > > stories could be used as I was attempting to use an agile practice in
                                        > > > a non-agile environment? Can agile work in such an environment?
                                        > > >
                                        > >
                                        > > Do you mean user stories in an otherwise non-agile approach? I am not
                                        > > sure if that can accomplish much.
                                        > >
                                        > > Do you mean every team iteratively delivers on a backlog, but the
                                        > > backlog for the architectural teams are the widgets that would seem to
                                        > > be generally useful for the user stories on the application teams'
                                        > > backlogs? It can work, just not as well as if the architectural teams
                                        > > directly collaborate on the application-level user stories. I would
                                        > > generally expect more bloat, more architecture that goes unused, more
                                        > > code complexity, a higher cost of maintenance, a higher cost of change
                                        > > and a slower responsiveness to change than there should have to be.
                                        > >
                                        > > Engineer utilization would likely be higher under this approach. But,
                                        > > is the goal to keep the engineers busy or minimize how long it takes
                                        > > to deliver features? This is a fallacy that project management falls
                                        > > into because a Gant Chart tells you that maximizing utilization will
                                        > > decrease how long it takes to deliver the whole project.
                                        > >
                                        > > Is the goal of a server farm to maximize utilization of the servers or
                                        > > minimize transaction times? Is the goal of building a new freeway to
                                        > > maximize the number of cars that use it or minimize how long it takes
                                        > > people to go from point A to point B? For some reason, people see the
                                        > > fallacy of maximizing utilization much better with inanimate objects
                                        > > than with people.
                                        > >
                                        > > Steve
                                        > >
                                        >
                                      • 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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.