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

Re: [agile-usability] Ownership outside of the SCRUM team

Expand Messages
  • 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 1 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 2 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 3 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 4 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.