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

Ownership outside of the SCRUM team

Expand Messages
  • Jeremy K
    The Crux of my question: SCRUM states that the product owner has to represent all stakeholders and be empowered to make decisions in order to move the team
    Message 1 of 20 , Oct 2, 2008
    • 0 Attachment
      The Crux of my question:
      SCRUM states that the product owner has to represent all stakeholders
      and be empowered to make decisions in order to move the team ahead
      quickly. How can that person do that on UE issues if they do not have
      the appropriate background? For the UE person on a team, when is
      external feedback from stakeholders suggestion vs. instruction?

      Context:
      I am the UE Lead in a company with 6 concurrent teams working on
      different projects which may be separate products or parts of the same
      product. It is a relatively young start-up with a team of mostly new
      people and we are only a few months into our adoption of agile. I am
      on no individual team, so qualify as a chicken in agile terms.

      I would define one of my responsibilities as keeping design
      consistency across the product. Design sensibility is not something
      easily captured in requirements, so I find it is hard for the product
      owner to represent me in the decision-making process for the team.

      There is a UE practitioner on the team and that person solicits
      feedback regularly. However, it is not clear whether external feedback
      should be taken as suggestion or instruction from certain stakeholders
      (myself, marketing, etc.). The product owner is new to agile and new
      to UE practice and does not have the experience or confidence to make
      definitive decisions on these issues.

      How have others dealt with this? Have there been instances of
      ownership/signoff that exist outside of the scrum team?

      Caveat: I know that user testing would help with this and we are doing
      much less than we should and working on doing more.

      Your feedback is greatly appreciated.

      jer
    • William Pietri
      Hi, Jeremy. Welcome to the group, and thanks for posting such a well thought out question. ... As far as I know, the only way for a product owner to learn to
      Message 2 of 20 , Oct 2, 2008
      • 0 Attachment
        Hi, Jeremy. Welcome to the group, and thanks for posting such a well
        thought out question.


        Jeremy K wrote:
        > I would define one of my responsibilities as keeping design
        > consistency across the product. Design sensibility is not something
        > easily captured in requirements, so I find it is hard for the product
        > owner to represent me in the decision-making process for the team.
        >
        > There is a UE practitioner on the team and that person solicits
        > feedback regularly. However, it is not clear whether external feedback
        > should be taken as suggestion or instruction from certain stakeholders
        > (myself, marketing, etc.). The product owner is new to agile and new
        > to UE practice and does not have the experience or confidence to make
        > definitive decisions on these issues.
        >
        > How have others dealt with this? Have there been instances of
        > ownership/signoff that exist outside of the scrum team?
        >

        As far as I know, the only way for a product owner to learn to make good
        decisions is to make them frequently, get plenty of feedback, and pay
        attention to the results. So I'd look to provide a fair bit of support
        in helping them understand the big-picture value of the things you're
        advocating for, both through pre-decision advice and post-decision data.

        The teams that I see working well have people with design sensibilities
        frequently or continually present as decisions get made. That includes
        the big decisions, like what goes into a release or an iteration.
        There, having a senior designer present is a big help. And it includes
        the little ones, where I see visual and/or interface designers
        physically near or working directly with developers, and reviewing work
        frequently.

        As far as coordinating the efforts of multiple teams, I see that happen
        mainly casually; designers show each other work in progress frequently,
        getting feedback and resolving differences. I also see occasional formal
        efforts to keep design consistent, where updating to a new visual style
        or interaction approach ends up in the queue for each team. And I also
        see good success with style guides, so that developers have a single
        place to turn to when they wonder what the right design approach is.

        Hoping that helps,

        William
      • Arlen Bankston
        ... Effective Product Owners (POs) should draw on feedback from the experts in order to make their decisions, and UE leads tend to be critical sources of input
        Message 3 of 20 , Oct 2, 2008
        • 0 Attachment
          > SCRUM states that the product owner has to represent all stakeholders
          > and be empowered to make decisions in order to move the team ahead
          > quickly. How can that person do that on UE issues if they do not have
          > the appropriate background?

          Effective Product Owners (POs) should draw on feedback from the
          experts in order to make their decisions, and UE leads tend to be
          critical sources of input (often the single most influential). Rarely
          will a PO actually possess enough domain expertise to make decisions
          from the business level down to the user interaction one, so they use
          the experts to A) generate options for them to consider, and B)
          present the relative pros/cons of each, so that they can make a
          rational choice about where and how to best invest.

          For the UE person on a team, when is
          > external feedback from stakeholders suggestion vs. instruction?

          Feedback from stakeholders is always instruction, from my perspective;
          it's input into a decision, variously informing a team what is
          important to users, what designs might best address certain problems,
          etc. POs must balance this sort of input across stakeholders,
          eventually deciding what to build in a manner that best fulfills their
          project's business case (maximizing cost/benefit).

          If "design sensibilities" are the key thing you're having trouble
          getting addressed properly, your most effective approach is probably
          going to be placing yourself in a position to facilitate design work
          across teams. The "Design Studio" approach described here is one idea
          for how to approach this: http://submissions.agile2008.org/node/4391

          You could also offer to help the customer team (PO and whomever else
          helps to write initial requirements) in formulating so-called
          Acceptance Criteria for individual requests (User Stories or whatever
          else you might be using) that capture usability criteria ("must
          provide visual feedback confirming submission," "must respond in <2
          seconds," etc).

          How are you currently integrated into the process? Most UEs
          essentially straddle the line between the PO side (giving advice on
          what features will delight users or stimulate most demand) and the
          Team (assisting in implementing these features in the most
          efficient/effective/appealing way)...

          BTW, I'm a Certified Scrum Trainer, for what it's worth. Hope this
          helps...

          Arlen

          --- In agile-usability@yahoogroups.com, "Jeremy K" <jer@...> wrote:
          >
          > The Crux of my question:

          >
          > Context:
          > I am the UE Lead in a company with 6 concurrent teams working on
          > different projects which may be separate products or parts of the same
          > product. It is a relatively young start-up with a team of mostly new
          > people and we are only a few months into our adoption of agile. I am
          > on no individual team, so qualify as a chicken in agile terms.
          >
          > I would define one of my responsibilities as keeping design
          > consistency across the product. Design sensibility is not something
          > easily captured in requirements, so I find it is hard for the product
          > owner to represent me in the decision-making process for the team.
          >
          > There is a UE practitioner on the team and that person solicits
          > feedback regularly. However, it is not clear whether external feedback
          > should be taken as suggestion or instruction from certain stakeholders
          > (myself, marketing, etc.). The product owner is new to agile and new
          > to UE practice and does not have the experience or confidence to make
          > definitive decisions on these issues.
          >
          > How have others dealt with this? Have there been instances of
          > ownership/signoff that exist outside of the scrum team?
          >
          > Caveat: I know that user testing would help with this and we are doing
          > much less than we should and working on doing more.
          >
          > Your feedback is greatly appreciated.
          >
          > jer
          >
        • Nick Gassman
          ... You need to adapt Agile methods to suit your organisation. I think I m in a similar position to you. I have agreements that the product owner won t make a
          Message 4 of 20 , Oct 15, 2008
          • 0 Attachment
            On Thu, 02 Oct 2008 17:21:30 -0000, jer wrote:

            >SCRUM states that the product owner has to represent all stakeholders
            >and be empowered to make decisions in order to move the team ahead
            >quickly. How can that person do that on UE issues if they do not have
            >the appropriate background? For the UE person on a team, when is
            >external feedback from stakeholders suggestion vs. instruction?

            You need to adapt Agile methods to suit your organisation.

            I think I'm in a similar position to you. I have agreements that the
            product owner won't make a decision without getting my input. Someone
            has to make a decision at the end of the day, and if they decide to
            ignore me, then there are business metrics to measure whether that was
            justified or not.

            It's important to build a reputation within your organisation. It
            works better if people **want** your input, rather than being required
            to get it.

            For consistency across projects, I will review all the designs with
            all the UX leads, so it's up to me, and them to talk to their
            colleagues. They will escalate consistency issues to me if they think
            they need to.

            * Nick Gassman - Usability and Standards Manager - http://ba.com *
          • Ron Jeffries
            Hello, Nick. On Wednesday, October 15, 2008, at 2:19:44 PM, you ... I m sure it would be good to be the king. However, in every product situation that I know
            Message 5 of 20 , Oct 15, 2008
            • 0 Attachment
              Hello, Nick. On Wednesday, October 15, 2008, at 2:19:44 PM, you
              wrote:

              > On Thu, 02 Oct 2008 17:21:30 -0000, jer wrote:

              >>SCRUM states that the product owner has to represent all stakeholders
              >>and be empowered to make decisions in order to move the team ahead
              >>quickly. How can that person do that on UE issues if they do not have
              >>the appropriate background? For the UE person on a team, when is
              >>external feedback from stakeholders suggestion vs. instruction?

              > You need to adapt Agile methods to suit your organisation.

              > I think I'm in a similar position to you. I have agreements that the
              > product owner won't make a decision without getting my input. Someone
              > has to make a decision at the end of the day, and if they decide to
              > ignore me, then there are business metrics to measure whether that was
              > justified or not.

              > It's important to build a reputation within your organisation. It
              > works better if people **want** your input, rather than being required
              > to get it.

              > For consistency across projects, I will review all the designs with
              > all the UX leads, so it's up to me, and them to talk to their
              > colleagues. They will escalate consistency issues to me if they think
              > they need to.

              I'm sure it would be good to be the king. However, in every product
              situation that I know of, including Scrum-based ones, the UE person
              is not king. His neck is too skinny to grab, for one thing.

              What that means, perforce, is that the UE folks are advisors to the
              king. The king might delegate a lot of authority to them, or might
              not. Either way the Product Owner has the responsibility and the
              ultimate authority in most real cases and, in my opinion, that's how
              it should be.

              So UE people learn to explain, persuade, and keep costs down, just
              like the rest of us, I guess.

              Ron Jeffries
              www.XProgramming.com
              www.xprogramming.com/blog
              Show me the features!
            • Robert Biddle
              I hope people don t mind, but I d like to go back a while and pick up some ideas I am still puzzled about. Here s one: ... I was a little confused about the
              Message 6 of 20 , Oct 25, 2008
              • 0 Attachment
                I hope people don't mind, but I'd like to go back a while and
                pick up some ideas I am still puzzled about. Here's one:

                Ron Jeffries wrote:
                > I'm sure it would be good to be the king. However, in every product
                > situation that I know of, including Scrum-based ones, the UE person
                > is not king. His neck is too skinny to grab, for one thing.
                >
                > What that means, perforce, is that the UE folks are advisors to the
                > king. The king might delegate a lot of authority to them, or might
                > not. Either way the Product Owner has the responsibility and the
                > ultimate authority in most real cases and, in my opinion, that's how
                > it should be.
                >
                > So UE people learn to explain, persuade, and keep costs down, just
                > like the rest of us, I guess.


                I was a little confused about "the rest of us". I guess you mean
                developers, but I am not quite sure. I certainly have seen a UE
                person be a product owner, by the way. The product was one where
                user experience was the main competetive aspect of the product,
                and she argued that having a UE person as product owner was
                therefore ideal.

                What really surprised me, though, is that you seem to be saying
                that the UE people should be part of "the team". I thought you
                didn't like that idea because the UE people are not doing what
                you consider to be "software developement". Have I missed
                something here?

                In particular, I want to consider the UE work like user research
                and early paper prototyping. It seems to me that this work might
                be considered as generating backlog stories, rather than building
                them. So do you consider that this work belongs to the same team
                that does the building of the stories? I can imagine how that
                might work, but I am not sure I have seen it. In some ways it
                seems to twist the main idea inside itself, and bring the role of
                the product owner into question. I can see that might be a
                plausible approach, meaning that there is no product owner
                but "the team". Maybe that's your point, but it seems to
                conflict with your comment about "how it should be".

                Anyway, I'd be interested to see more explanation.

                Robert
              • Ron Jeffries
                Hello, Robert. On Saturday, October 25, 2008, at 7:40:43 AM, you ... By rest of us I mean everyone who is not the Product Owner, whether developer, tester,
                Message 7 of 20 , Oct 25, 2008
                • 0 Attachment
                  Hello, Robert. On Saturday, October 25, 2008, at 7:40:43 AM, you
                  wrote:

                  > I hope people don't mind, but I'd like to go back a while and
                  > pick up some ideas I am still puzzled about. Here's one:

                  > Ron Jeffries wrote:
                  >> I'm sure it would be good to be the king. However, in every product
                  >> situation that I know of, including Scrum-based ones, the UE person
                  >> is not king. His neck is too skinny to grab, for one thing.
                  >>
                  >> What that means, perforce, is that the UE folks are advisors to the
                  >> king. The king might delegate a lot of authority to them, or might
                  >> not. Either way the Product Owner has the responsibility and the
                  >> ultimate authority in most real cases and, in my opinion, that's how
                  >> it should be.
                  >>
                  >> So UE people learn to explain, persuade, and keep costs down, just
                  >> like the rest of us, I guess.


                  > I was a little confused about "the rest of us". I guess you mean
                  > developers, but I am not quite sure. I certainly have seen a UE
                  > person be a product owner, by the way. The product was one where
                  > user experience was the main competetive aspect of the product,
                  > and she argued that having a UE person as product owner was
                  > therefore ideal.

                  By "rest of us" I mean everyone who is not the Product Owner,
                  whether developer, tester, UE person, stakeholder, etc.

                  My point was that generally UE people do not have the power that the
                  OP seemed to wish they would have, and that such a person would have
                  to negotiate like everyone else.

                  > What really surprised me, though, is that you seem to be saying
                  > that the UE people should be part of "the team". I thought you
                  > didn't like that idea because the UE people are not doing what
                  > you consider to be "software developement". Have I missed
                  > something here?

                  I would say so. I think there is only the team. The existence of a
                  dedicated team is near core to Agile. People who are part of the
                  project but not of the team are a red flag from the Agile viewpoint,
                  I would say.

                  > In particular, I want to consider the UE work like user research
                  > and early paper prototyping. It seems to me that this work might
                  > be considered as generating backlog stories, rather than building
                  > them. So do you consider that this work belongs to the same team
                  > that does the building of the stories? I can imagine how that
                  > might work, but I am not sure I have seen it. In some ways it
                  > seems to twist the main idea inside itself, and bring the role of
                  > the product owner into question. I can see that might be a
                  > plausible approach, meaning that there is no product owner
                  > but "the team". Maybe that's your point, but it seems to
                  > conflict with your comment about "how it should be".

                  I think one could argue that the team should be some whole object
                  that is guided by some kind of consensus but I think this is perhaps
                  too idealistic even for me. In any case, in business as it is done
                  today, there is likely to be a designated person, which in Agile we
                  would call customer or product owner.

                  > Anyway, I'd be interested to see more explanation.



                  Ron Jeffries
                  www.XProgramming.com
                  www.xprogramming.com/blog
                  Speak the affirmative; emphasize your choice
                  by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                • Ron Jeffries
                  Hello, Robert. Hmm, wasn t quite finished with that and it flew off. Changes down at the bottom. On Saturday, October 25, 2008, at 7:40:43 AM, you ... By rest
                  Message 8 of 20 , Oct 25, 2008
                  • 0 Attachment
                    Hello, Robert.

                    Hmm, wasn't quite finished with that and it flew off. Changes down
                    at the bottom.

                    On Saturday, October 25, 2008, at 7:40:43 AM, you
                    wrote:

                    > I hope people don't mind, but I'd like to go back a while and
                    > pick up some ideas I am still puzzled about. Here's one:

                    > Ron Jeffries wrote:
                    >> I'm sure it would be good to be the king. However, in every product
                    >> situation that I know of, including Scrum-based ones, the UE person
                    >> is not king. His neck is too skinny to grab, for one thing.
                    >>
                    >> What that means, perforce, is that the UE folks are advisors to the
                    >> king. The king might delegate a lot of authority to them, or might
                    >> not. Either way the Product Owner has the responsibility and the
                    >> ultimate authority in most real cases and, in my opinion, that's how
                    >> it should be.
                    >>
                    >> So UE people learn to explain, persuade, and keep costs down, just
                    >> like the rest of us, I guess.


                    > I was a little confused about "the rest of us". I guess you mean
                    > developers, but I am not quite sure. I certainly have seen a UE
                    > person be a product owner, by the way. The product was one where
                    > user experience was the main competetive aspect of the product,
                    > and she argued that having a UE person as product owner was
                    > therefore ideal.

                    By "rest of us" I mean everyone who is not the Product Owner,
                    whether developer, tester, UE person, stakeholder, etc.

                    My point was that generally UE people do not have the power that the
                    OP seemed to wish they would have, and that such a person would have
                    to negotiate like everyone else.

                    > What really surprised me, though, is that you seem to be saying
                    > that the UE people should be part of "the team". I thought you
                    > didn't like that idea because the UE people are not doing what
                    > you consider to be "software developement". Have I missed
                    > something here?

                    I would say so. I think there is only the team. The existence of a
                    dedicated team is near core to Agile. People who are part of the
                    project but not of the team are a red flag from the Agile viewpoint,
                    I would say.

                    > In particular, I want to consider the UE work like user research
                    > and early paper prototyping. It seems to me that this work might
                    > be considered as generating backlog stories, rather than building
                    > them. So do you consider that this work belongs to the same team
                    > that does the building of the stories? I can imagine how that
                    > might work, but I am not sure I have seen it. In some ways it
                    > seems to twist the main idea inside itself, and bring the role of
                    > the product owner into question. I can see that might be a
                    > plausible approach, meaning that there is no product owner
                    > but "the team". Maybe that's your point, but it seems to
                    > conflict with your comment about "how it should be".

                    I think one could argue that the team should be some whole object
                    that is guided by some kind of consensus but I think this is perhaps
                    too idealistic even for me. In any case, in business as it is done
                    today, there is likely to be a designated person, which in Agile we
                    would call customer or product owner.

                    When such a person is designated, and whether or not they "delegate"
                    some of the decisions, the buck stops with them and everyone else
                    essentially relates to them as advisor.

                    > Anyway, I'd be interested to see more explanation.

                    Be careful what you ask for. :)

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    Speak the affirmative; emphasize your choice
                    by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                  • William Pietri
                    ... I think the two scenarios, consensus and delegation, are surprisingly compatible. Most of my work is with startups, and often the initial founders are all
                    Message 9 of 20 , Oct 25, 2008
                    • 0 Attachment
                      Ron Jeffries wrote:
                      > I think one could argue that the team should be some whole object
                      > that is guided by some kind of consensus but I think this is perhaps
                      > too idealistic even for me. In any case, in business as it is done
                      > today, there is likely to be a designated person, which in Agile we
                      > would call customer or product owner.
                      >

                      I think the two scenarios, consensus and delegation, are surprisingly
                      compatible.

                      Most of my work is with startups, and often the initial founders are all
                      peers. But having everybody involved in every decision is painfully
                      time-consuming, and so a consensus usually emerges where the team
                      delegates most of some kind of work to a particular person, and
                      generally trusts them with it. Sure, person X is officially the product
                      manager and makes a lot of the product calls, but they're accountable to
                      the whole team.

                      Just yesterday I saw a retrospective, where the whole team felt that the
                      product manager was too busy, causing a number of problems. So I saw
                      developers insisting that the product manager delegate more of the scut
                      work of product management to them. Not because they personally wanted
                      to do it, but because they thought that would make them more effective
                      as a team.

                      If you diagram that as a normal corporate dominance hierarchy, it's
                      pretty twisty. I guess it would be the developers as shareholders
                      putting pressure on the executives to order the product manager to
                      delegate more work to the developers, and also pressuring the VP of
                      engineering to force the developers to pick up product work. But in
                      their consensus approach, the team is eager to do their work as
                      effectively as possible, so the team regularly rebalances the workload.
                      Seems simpler to me.


                      William
                    • Robert Biddle
                      Hi Ron, and thanks: Just a followup question while I mull this over. Are you suggesting the situation you describe for Scrum or XP or both? In particular, are
                      Message 10 of 20 , Oct 25, 2008
                      • 0 Attachment
                        Hi Ron, and thanks:

                        Just a followup question while I mull this over.
                        Are you suggesting the situation you describe
                        for Scrum or XP or both?

                        In particular, are you happy with people who
                        do no programming or program testing being on
                        the team? For example, people such as user researchers
                        or market analysts?

                        Robt

                        Ron Jeffries wrote:
                        >
                        > Hello, Robert.
                        >
                        > Hmm, wasn't quite finished with that and it flew off. Changes down
                        > at the bottom.
                        >
                        > On Saturday, October 25, 2008, at 7:40:43 AM, you
                        > wrote:
                        >
                        > > I hope people don't mind, but I'd like to go back a while and
                        > > pick up some ideas I am still puzzled about. Here's one:
                        >
                        > > Ron Jeffries wrote:
                        > >> I'm sure it would be good to be the king. However, in every product
                        > >> situation that I know of, including Scrum-based ones, the UE person
                        > >> is not king. His neck is too skinny to grab, for one thing.
                        > >>
                        > >> What that means, perforce, is that the UE folks are advisors to the
                        > >> king. The king might delegate a lot of authority to them, or might
                        > >> not. Either way the Product Owner has the responsibility and the
                        > >> ultimate authority in most real cases and, in my opinion, that's how
                        > >> it should be.
                        > >>
                        > >> So UE people learn to explain, persuade, and keep costs down, just
                        > >> like the rest of us, I guess.
                        >
                        > > I was a little confused about "the rest of us". I guess you mean
                        > > developers, but I am not quite sure. I certainly have seen a UE
                        > > person be a product owner, by the way. The product was one where
                        > > user experience was the main competetive aspect of the product,
                        > > and she argued that having a UE person as product owner was
                        > > therefore ideal.
                        >
                        > By "rest of us" I mean everyone who is not the Product Owner,
                        > whether developer, tester, UE person, stakeholder, etc.
                        >
                        > My point was that generally UE people do not have the power that the
                        > OP seemed to wish they would have, and that such a person would have
                        > to negotiate like everyone else.
                        >
                        > > What really surprised me, though, is that you seem to be saying
                        > > that the UE people should be part of "the team". I thought you
                        > > didn't like that idea because the UE people are not doing what
                        > > you consider to be "software developement". Have I missed
                        > > something here?
                        >
                        > I would say so. I think there is only the team. The existence of a
                        > dedicated team is near core to Agile. People who are part of the
                        > project but not of the team are a red flag from the Agile viewpoint,
                        > I would say.
                        >
                        > > In particular, I want to consider the UE work like user research
                        > > and early paper prototyping. It seems to me that this work might
                        > > be considered as generating backlog stories, rather than building
                        > > them. So do you consider that this work belongs to the same team
                        > > that does the building of the stories? I can imagine how that
                        > > might work, but I am not sure I have seen it. In some ways it
                        > > seems to twist the main idea inside itself, and bring the role of
                        > > the product owner into question. I can see that might be a
                        > > plausible approach, meaning that there is no product owner
                        > > but "the team". Maybe that's your point, but it seems to
                        > > conflict with your comment about "how it should be".
                        >
                        > I think one could argue that the team should be some whole object
                        > that is guided by some kind of consensus but I think this is perhaps
                        > too idealistic even for me. In any case, in business as it is done
                        > today, there is likely to be a designated person, which in Agile we
                        > would call customer or product owner.
                        >
                        > When such a person is designated, and whether or not they "delegate"
                        > some of the decisions, the buck stops with them and everyone else
                        > essentially relates to them as advisor.
                        >
                        > > Anyway, I'd be interested to see more explanation.
                        >
                        > Be careful what you ask for. :)
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > www.xprogramming.com/blog
                        > Speak the affirmative; emphasize your choice
                        > by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                        >
                        >
                      • Ron Jeffries
                        Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you ... For me, both. ... Sure. They are part of the customer sub-team I should think. Ron
                        Message 11 of 20 , Oct 25, 2008
                        • 0 Attachment
                          Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you
                          wrote:

                          > Just a followup question while I mull this over.
                          > Are you suggesting the situation you describe
                          > for Scrum or XP or both?

                          For me, both.

                          > In particular, are you happy with people who
                          > do no programming or program testing being on
                          > the team? For example, people such as user researchers
                          > or market analysts?

                          Sure. They are part of the customer sub-team I should think.

                          Ron Jeffries
                          www.XProgramming.com
                          www.xprogramming.com/blog
                          Education is the ability to listen to almost anything without losing
                          your temper or your self-confidence. --Robert Frost
                        • Robert Biddle
                          Ok, so my next followup is this: In the approach you describe, * is all work done organized as stories/backlog-items, even those which are distant from user
                          Message 12 of 20 , Oct 25, 2008
                          • 0 Attachment
                            Ok, so my next followup is this:

                            In the approach you describe,
                            * is all work done organized as stories/backlog-items, even those which are
                            distant from user interaction (e.g. estimate viable market size for
                            release 1)?
                            * are all team members on the project full time from start to finish?

                            I think it's an interesting idea, if so, but I'm not sure how practical
                            the second
                            point (above) would be.
                            I've never seen a project run like this, by the way.

                            Robt


                            Ron Jeffries wrote:
                            >
                            > Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you
                            > wrote:
                            >
                            > > Just a followup question while I mull this over.
                            > > Are you suggesting the situation you describe
                            > > for Scrum or XP or both?
                            >
                            > For me, both.
                            >
                            > > In particular, are you happy with people who
                            > > do no programming or program testing being on
                            > > the team? For example, people such as user researchers
                            > > or market analysts?
                            >
                            > Sure. They are part of the customer sub-team I should think.
                            >
                            > Ron Jeffries
                            > www.XProgramming.com
                            > www.xprogramming.com/blog
                            > Education is the ability to listen to almost anything without losing
                            > your temper or your self-confidence. --Robert Frost
                            >
                            >
                          • Ron Jeffries
                            Hello, Robert. On Saturday, October 25, 2008, at 4:19:36 PM, you ... I prefer that the product backlog contain only software items. Teams that put other stuff
                            Message 13 of 20 , Oct 25, 2008
                            • 0 Attachment
                              Hello, Robert. On Saturday, October 25, 2008, at 4:19:36 PM, you
                              wrote:

                              > In the approach you describe,
                              > * is all work done organized as stories/backlog-items, even those which are
                              > distant from user interaction (e.g. estimate viable market size for
                              > release 1)?

                              I prefer that the product backlog contain only software items. Teams
                              that put other stuff on the backlog seem to be the ones who can't
                              ever get any software done.

                              Using a backlog for other activities seems to me to be in general a
                              good idea, such as remembering to buy socks. But teams who put
                              sock-buying on an even par with software get in trouble. Does this
                              suggest more than one backlog? Could be ...

                              > * are all team members on the project full time from start to finish?

                              > I think it's an interesting idea, if so, but I'm not sure how practical
                              > the second
                              > point (above) would be.
                              > I've never seen a project run like this, by the way.

                              I think people should either be on the team, or not on the team. If
                              someone came in, completed something, and left, that would be fine.
                              Shared resources become bottlenecks as a mathematical certainty.
                              That seems to me to be either inherently bad, or such an advanced
                              approach that no one should try it.

                              Ron Jeffries
                              www.XProgramming.com
                              www.xprogramming.com/blog
                              If you want to garden, you have to bend down and touch the soil.
                              Gardening is a practice, not an idea.
                              -- Thich Nhat Hanh
                            • Ron Jeffries
                              Hello, William. On Saturday, October 25, 2008, at 3:21:58 PM, you ... No doubt it is, when it is possible at all. I do not find that most corporations, nor
                              Message 14 of 20 , Oct 25, 2008
                              • 0 Attachment
                                Hello, William. On Saturday, October 25, 2008, at 3:21:58 PM, you
                                wrote:

                                > Seems simpler to me.

                                No doubt it is, when it is possible at all. I do not find that most
                                corporations, nor most projects, work by consensus, however.

                                Ron Jeffries
                                www.XProgramming.com
                                www.xprogramming.com/blog
                                The truth ain't like puppies, a bunch of 'em runnin' around
                                and you pick your favorite. --Emerson Codd
                              • William Pietri
                                Hi, Robert. Hope you don t mind me butting in. For the teams I work with, the main work queue is about released software. Most of the cards in that queue
                                Message 15 of 20 , Oct 25, 2008
                                • 0 Attachment
                                  Hi, Robert. Hope you don't mind me butting in.

                                  For the teams I work with, the main work queue is about released software. Most of the cards in that queue involve at least some amount of UI design, visual design, front-end coding, and back-end coding. Some engineering research ends up in that queue as well, either when it's large enough to have a schedule impact or has a deliverable. That deliverable is usually an estimate on some other set of cards.

                                  Other kinds of thinking, research, and effort tend to be driven by that queue, but not kept in it. That includes engineering work, business work, and design work. A lot of people manage the schedule for that other work intuitively, but I also see separate formal queues kept for individuals or functions. E.g., one team is going to try a visible, card-based queue for product management work, so the product manager's workload is more visible, and so that some of the work can be shared.

                                  William

                                  Robert Biddle wrote:
                                  Ok, so my next followup is this:
                                  
                                  In the approach you describe,
                                  * is all work done organized as stories/backlog-items, even those which are
                                     distant from user interaction (e.g. estimate viable market size for 
                                  release 1)?
                                  * are all team members on the project full time from start to finish?
                                  
                                  I think it's an interesting idea, if so, but I'm not sure how practical 
                                  the second
                                  point (above) would be.
                                  I've never seen a project run like this, by the way.
                                  
                                  Robt
                                  
                                  
                                  Ron Jeffries wrote:
                                    
                                  Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you
                                  wrote:
                                  
                                      
                                  Just a followup question while I mull this over.
                                  Are you suggesting the situation you describe
                                  for Scrum or XP or both?
                                        
                                  For me, both.
                                  
                                      
                                  In particular, are you happy with people who
                                  do no programming or program testing being on
                                  the team? For example, people such as user researchers
                                  or market analysts?
                                        
                                  Sure. They are part of the customer sub-team I should think.
                                  
                                  Ron Jeffries
                                  www.XProgramming.com
                                  www.xprogramming.com/blog
                                  Education is the ability to listen to almost anything without losing
                                  your temper or your self-confidence. --Robert Frost
                                  
                                   
                                      
                                  
                                  ------------------------------------
                                  
                                  Yahoo! Groups Links
                                  
                                  <*> To visit your group on the web, go to:
                                      http://groups.yahoo.com/group/agile-usability/
                                  
                                  <*> Your email settings:
                                      Individual Email | Traditional
                                  
                                  <*> To change settings online go to:
                                      http://groups.yahoo.com/group/agile-usability/join
                                      (Yahoo! ID required)
                                  
                                  <*> To change settings via email:
                                      mailto:agile-usability-digest@yahoogroups.com 
                                      mailto:agile-usability-fullfeatured@yahoogroups.com
                                  
                                  <*> To unsubscribe from this group, send an email to:
                                      agile-usability-unsubscribe@yahoogroups.com
                                  
                                  <*> Your use of Yahoo! Groups is subject to:
                                      http://docs.yahoo.com/info/terms/
                                  
                                    

                                • Robert Biddle
                                  Interesting. I can see both points as plausible, but the second (full time on the team) seems problematic. It depends on the size of the project, of course,
                                  Message 16 of 20 , Oct 25, 2008
                                  • 0 Attachment
                                    Interesting. I can see both points as plausible,
                                    but the second (full time on the team) seems problematic.
                                    It depends on the size of the project, of course, but when
                                    we are talking about all the kind of people involved, not just developers,
                                    it seems to suggest that small projects would either do without some
                                    necessary skills, or underutilize some expensive people.
                                    For example, marketing people and graphic artists: I can see
                                    many small projects needing some of both such skills, but
                                    often not enough to justify full time assignment.
                                    I do agree it's a difficult matter, but I don't see an easy answer.
                                    Robt


                                    Ron Jeffries wrote:
                                    >
                                    > Hello, Robert. On Saturday, October 25, 2008, at 4:19:36 PM, you
                                    > wrote:
                                    >
                                    > > In the approach you describe,
                                    > > * is all work done organized as stories/backlog-items, even those
                                    > which are
                                    > > distant from user interaction (e.g. estimate viable market size for
                                    > > release 1)?
                                    >
                                    > I prefer that the product backlog contain only software items. Teams
                                    > that put other stuff on the backlog seem to be the ones who can't
                                    > ever get any software done.
                                    >
                                    > Using a backlog for other activities seems to me to be in general a
                                    > good idea, such as remembering to buy socks. But teams who put
                                    > sock-buying on an even par with software get in trouble. Does this
                                    > suggest more than one backlog? Could be ...
                                    >
                                    > > * are all team members on the project full time from start to finish?
                                    >
                                    > > I think it's an interesting idea, if so, but I'm not sure how practical
                                    > > the second
                                    > > point (above) would be.
                                    > > I've never seen a project run like this, by the way.
                                    >
                                    > I think people should either be on the team, or not on the team. If
                                    > someone came in, completed something, and left, that would be fine.
                                    > Shared resources become bottlenecks as a mathematical certainty.
                                    > That seems to me to be either inherently bad, or such an advanced
                                    > approach that no one should try it.
                                    >
                                    > Ron Jeffries
                                    > www.XProgramming.com
                                    > www.xprogramming.com/blog
                                    > If you want to garden, you have to bend down and touch the soil.
                                    > Gardening is a practice, not an idea.
                                    > -- Thich Nhat Hanh
                                    >
                                    >
                                  • Ron Jeffries
                                    Hello, Robert. On Saturday, October 25, 2008, at 10:35:21 PM, you ... Yes. We need to observe that when people are shared across projects, both the projects
                                    Message 17 of 20 , Oct 26, 2008
                                    • 0 Attachment
                                      Hello, Robert. On Saturday, October 25, 2008, at 10:35:21 PM, you
                                      wrote:

                                      > Interesting. I can see both points as plausible,
                                      > but the second (full time on the team) seems problematic.
                                      > It depends on the size of the project, of course, but when
                                      > we are talking about all the kind of people involved, not just developers,
                                      > it seems to suggest that small projects would either do without some
                                      > necessary skills, or underutilize some expensive people.
                                      > For example, marketing people and graphic artists: I can see
                                      > many small projects needing some of both such skills, but
                                      > often not enough to justify full time assignment.

                                      Yes. We need to observe that when people are shared across projects,
                                      both the projects and the persons quite likely may be operating less
                                      effectively than they might. Often, "resource" sharing is undertaken
                                      without a clear understanding of its costs. That's not ideal either.

                                      > I do agree it's a difficult matter, but I don't see an easy answer.

                                      I don't think this work would be very interesting if the answers
                                      were easy. However I think the best answers are more simple than the
                                      answers we usually wind up with. :)

                                      Ron Jeffries
                                      www.XProgramming.com
                                      www.xprogramming.com/blog
                                      I'm not bad, I'm just drawn that way. -- Jessica Rabbit
                                    • William Pietri
                                      ... I think the best way to deal with this dilemma is to a) fight hard to get every important contributor physically present, and b) make sure that anybody who
                                      Message 18 of 20 , Oct 26, 2008
                                      • 0 Attachment
                                        Ron Jeffries wrote:
                                        Hello, Robert.  On Saturday, October 25, 2008, at 10:35:21 PM, you
                                        wrote:
                                        
                                          
                                        It depends on the size of the project, of course, but when
                                        we are talking about all the kind of people involved, not just developers,
                                        it seems to suggest that small projects would either do without some
                                        necessary skills, or underutilize some expensive people.
                                        For example, marketing people and graphic artists: I can see
                                        many small projects needing some of both such skills, but
                                        often not enough to justify full time assignment.
                                            
                                        Yes. We need to observe that when people are shared across projects,
                                        both the projects and the persons quite likely may be operating less
                                        effectively than they might. Often, "resource" sharing is undertaken
                                        without a clear understanding of its costs. That's not ideal either.
                                          

                                        I think the best way to deal with this dilemma is to a) fight hard to get every important contributor physically present, and b) make sure that anybody who can't be physically present is well represented.

                                        A team may not have a full-time graphic designer, but they could well have a UI designer, or a front-end engineer who has an appreciation for good visual design. A full-time user researcher is unlikely, but a product manager can learn when more data would help, and what results came out of recent testing. Those present can represent those who can't be, and call them in when necessary.

                                        I do think this proxy relationship should be both explicit and personal. If a designer on a project is also representing the rest of the design department, there should be clear mutual accountability. And although the team as a whole is responsible for a good product, some individual should be the designated contact, or it's too easy for things to fall through the cracks.

                                        Shared resources are definitely not a local optimum, but I will grudgingly concede that they can be a global one. As long as, like Ron says, the full cost of splitting is truly understood.

                                        William
                                      • Tim Wright
                                        Hi everyone (and a particular hello to Robert :) Oddly, I m doing usability on an agile team at the moment - and we re using Scrum to do it. The odd thing
                                        Message 19 of 20 , Oct 27, 2008
                                        • 0 Attachment
                                          Hi everyone (and a particular hello to Robert :)

                                          Oddly, I'm doing usability on an agile team at the moment - and we're using Scrum to do it. The odd thing about the current sprint (and the first sprint of the project) is that there is only 1 item on the product backlog. There are about 5 documents for our funding committee and some infrastructure stuff to prepare for future sprints. While I can't give any feedback on the usability side yet, the documentation side seems to work very well in the environment and lets the backlog owner (who is also the product owner) really focus the resources on the team on what the team needs to do to succeed - be that get the documentation ready so we have funding into 2009, or write code.

                                          (the organization I work for hasn't done agile in the past and has a funding model more suitable for waterfall development projects. However, we're working on helping them understand the approach and working within the constraints of the project).

                                          Tim

                                          On Sun, Oct 26, 2008 at 9:32 AM, Ron Jeffries <ronjeffries@...> wrote:

                                          Hello, Robert. On Saturday, October 25, 2008, at 4:19:36 PM, you
                                          wrote:



                                          > In the approach you describe,
                                          > * is all work done organized as stories/backlog-items, even those which are
                                          > distant from user interaction (e.g. estimate viable market size for
                                          > release 1)?

                                          I prefer that the product backlog contain only software items. Teams
                                          that put other stuff on the backlog seem to be the ones who can't
                                          ever get any software done.

                                          Using a backlog for other activities seems to me to be in general a
                                          good idea, such as remembering to buy socks. But teams who put
                                          sock-buying on an even par with software get in trouble. Does this
                                          suggest more than one backlog? Could be ...



                                          --
                                          Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua. Kōrero ai tiki tāua.
                                        • Gerard Meszaros
                                          We ve used this concept of separate backlogs for different subteams on some projects. For example, a software development backlog and a product design backlog.
                                          Message 20 of 20 , Oct 28, 2008
                                          • 0 Attachment
                                            We've used this concept of separate backlogs for different subteams on some projects. For example, a software development backlog and a product design backlog. "Half-baked stories" went into the product design backlog and were turned into "fully baked stories" that ultimately went into the s/w dev't backlog. The PD backlog was worked by the business team, which included the product owner, several other business resources, a BA/UE person and a tester. This seemed to work pretty well as it allowed us to track the velocity of the s/w development team better than when the half-baked stories were in the main backlog. One thing it really helped was reducing the variability in the estimates because the fully baked stories were usually much better understood and much more focused on the high value portions of the half-baked stories. The two subteams were in the same room and collaborated continously so they were still part of the same team, just responsible for different backlogs.

                                            Gerard
                                            -- 
                                            Gerard Meszaros
                                            Lean/Agile Coach/Mentor/Trainer
                                            http://www.gerardmeszaros.com 
                                            
                                            Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html


                                            William Pietri wrote:

                                            Hi, Robert. Hope you don't mind me butting in.

                                            For the teams I work with, the main work queue is about released software. Most of the cards in that queue involve at least some amount of UI design, visual design, front-end coding, and back-end coding. Some engineering research ends up in that queue as well, either when it's large enough to have a schedule impact or has a deliverable. That deliverable is usually an estimate on some other set of cards.

                                            Other kinds of thinking, research, and effort tend to be driven by that queue, but not kept in it. That includes engineering work, business work, and design work. A lot of people manage the schedule for that other work intuitively, but I also see separate formal queues kept for individuals or functions. E.g., one team is going to try a visible, card-based queue for product management work, so the product manager's workload is more visible, and so that some of the work can be shared.

                                            William

                                            Robert Biddle wrote:

                                            Ok, so my next followup is this:
                                            
                                            In the approach you describe,
                                            * is all work done organized as stories/backlog- items, even those which are
                                               distant from user interaction (e.g. estimate viable market size for 
                                            release 1)?
                                            * are all team members on the project full time from start to finish?
                                            
                                            I think it's an interesting idea, if so, but I'm not sure how practical 
                                            the second
                                            point (above) would be.
                                            I've never seen a project run like this, by the way.
                                            
                                            Robt
                                            
                                            
                                            Ron Jeffries wrote:
                                              
                                            Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you
                                            wrote:
                                            
                                                
                                            Just a followup question while I mull this over.
                                            Are you suggesting the situation you describe
                                            for Scrum or XP or both?
                                                  
                                            For me, both.
                                            
                                                
                                            In particular, are you happy with people who
                                            do no programming or program testing being on
                                            the team? For example, people such as user researchers
                                            or market analysts?
                                                  
                                            Sure. They are part of the customer sub-team I should think.
                                            
                                            Ron Jeffries
                                            www.XProgramming. com
                                            www.xprogramming. com/blog
                                            Education is the ability to listen to almost anything without losing
                                            your temper or your self-confidence. --Robert Frost
                                            
                                             
                                                
                                            
                                            ------------ --------- --------- ------
                                            
                                            Yahoo! Groups Links
                                            
                                            <*> To visit your group on the web, go to:
                                                http://groups. yahoo.com/ group/agile- usability/
                                            
                                            <*> Your email settings:
                                                Individual Email | Traditional
                                            
                                            <*> To change settings online go to:
                                                http://groups. yahoo.com/ group/agile- usability/ join
                                                (Yahoo! ID required)
                                            
                                            <*> To change settings via email:
                                                mailto:agile- usability- digest@yahoogrou ps.com 
                                                mailto:agile- usability- fullfeatured@ yahoogroups. com
                                            
                                            <*> To unsubscribe from this group, send an email to:
                                                agile-usability- unsubscribe@ yahoogroups. com
                                            
                                            <*> Your use of Yahoo! Groups is subject to:
                                                http://docs. yahoo.com/ info/terms/
                                            
                                              


                                            
                                            
                                            
                                            
                                            
                                          Your message has been successfully submitted and would be delivered to recipients shortly.