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

Re: Ownership outside of the SCRUM team

Expand Messages
  • 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 1 of 20 , Oct 2, 2008
      > 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 2 of 20 , Oct 15, 2008
        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 3 of 20 , Oct 15, 2008
          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 4 of 20 , Oct 25, 2008
            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 5 of 20 , Oct 25, 2008
              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 6 of 20 , Oct 25, 2008
                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 7 of 20 , Oct 25, 2008
                  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 8 of 20 , Oct 25, 2008
                    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 9 of 20 , Oct 25, 2008
                      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 10 of 20 , Oct 25, 2008
                        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 11 of 20 , Oct 25, 2008
                          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 12 of 20 , Oct 25, 2008
                            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 13 of 20 , Oct 25, 2008
                              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 14 of 20 , Oct 25, 2008
                                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 15 of 20 , Oct 26, 2008
                                  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 16 of 20 , Oct 26, 2008
                                    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 17 of 20 , Oct 27, 2008
                                      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 18 of 20 , Oct 28, 2008
                                        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.