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

Agile and UX for Product Suite??

Expand Messages
  • Carey Caulfield
    Hello All Anyone working on a web application that is a part of a suite of other products using Agile? Basically, we have a 3 product suite. 2 of the products
    Message 1 of 4 , Jun 20, 2008
      Agile and UX for Product Suite??

      Hello All

      Anyone working on a web application that is a part of a suite of other products using Agile?

      Basically, we have a 3 product suite. 2 of the products have been finishing up a release using Waterfall. I'm working on the 3rd product to the suite and we went ahead and are using Scrum. It is working really well, we are on Sprint 4.

      When the two other products release, the tentative plan is to have them go Scrum. Because there are shared components there will be a shared backlog for all three products. I don't think it's clear to anyone, even the 3 separate Product Owners how it's all going to work.

      Specific Questions
      1. Should there even be a shared backlog? Has anyone ever seen this work?

      2. What about shared UI? Anyone have experience working on different Scrums for different products yet having to collaborate with other UI Designers because of shared components? (Example: A Management Center where a Manager can turn on/off features for each of the products.) Tips for making this work???

      3. What if I want to make a big usability change to a shared area and my PO agrees. But the other designer and PO don't agree. Who wins?

      I'm pretty sure we'll figure it out. But was wondering if anyone else had the same going on. Like I say, it's going really well as the lone UI/UX designer for one product. Engineers and Product Owner and I are constantly talking, working quickly and getting the user stories done. But I'm worried about being slowed down when we have to reach concensus with the other designer and or other Product Owners.

      Thanks everyone!
      Carey




    • William Pietri
      Hi, Carey. I m sure others will have interesting answers, but here s what I ve seen. ... I ve seen shared priorities, but not shared backlogs. E.g., the
      Message 2 of 4 , Jun 20, 2008
        Hi, Carey. I'm sure others will have interesting answers, but here's what I've seen.

        Carey Caulfield wrote:
        Agile and UX for Product Suite??

        Basically, we have a 3 product suite. 2 of the products have been finishing up a release using Waterfall. I'm working on the 3rd product to the suite and we went ahead and are using Scrum. It is working really well, we are on Sprint 4. [...]

         
        1. Should there even be a shared backlog? Has anyone ever seen this work?


        I've seen shared priorities, but not shared backlogs. E.g., the product managers get together and talk over their broader goals and coordinate as necessary, but manage per-product backlogs. Generally I think of a backlog as a team's work queue.

        Sometimes I do see cross-team items. E.g., the team for Product A needs a feature in Product B. Some places Team A just works in Product B's code base, but in others Team A will ask Team B to do a little work for them. Either can make sense depending on the situation.

        3. What if I want to make a big usability change to a shared area and my PO agrees. But the other designer and PO don't agree. Who wins?

        Nobody, in the sense that winning battles over shared resources is a way to lose the war for great products. This is a prime opportunity to apply the "people over process" principle and find some way to come to a shared approach.

        If you and another designer are really at an impasse, one option is getting hard data to settle it. E.g., you each make a paper prototype of your proposed design and do some user testing. Hopefully after you've agreed to abide by the result. This approach is one I've stolen from "Getting to Yes," and it's full of other good advice on negotiating in ways that build consensus and strengthen relationships.

        William

      • Jim Ungar
        Carey - 1. Should there even be a shared backlog? Has anyone ever seen this work? Yes. We use the shared backlog - we call it a key tasks board - to tackle
        Message 3 of 4 , Jun 21, 2008
          Carey -


          1. Should there even be a shared backlog? Has anyone ever seen this work?

          Yes. We use the shared backlog - we call it a key tasks board - to  tackle items that impact multiple teams - infrastucture upgrades, shared component changes, etc. The team that picks up one of these backlog items becomes the 'owner' of that item.

          2. What about shared UI? Anyone have experience working on different Scrums for different products yet having to collaborate with other UI Designers because of shared components? (Example: A Management Center where a Manager can turn on/off features for each of the products.) Tips for making this work???

          I collaborate with other designers whenever possible. It always results in an improved design.

          3. What if I want to make a big usability change to a shared area and my PO agrees. But the other designer and PO don't agree. Who wins?

          Like William said, Nobody. However, if you transfer ownership of shared components, then the question is moot - the product owner and team makes the call, and presumably the issue has received high enough priority to engage a team. Let the Scrum process work for you here.


          Jim



          On Fri, Jun 20, 2008 at 5:51 PM, Carey Caulfield <carey.caulfield@...> wrote:

          Hello All

          Anyone working on a web application that is a part of a suite of other products using Agile?

          Basically, we have a 3 product suite. 2 of the products have been finishing up a release using Waterfall. I'm working on the 3rd product to the suite and we went ahead and are using Scrum. It is working really well, we are on Sprint 4.

          When the two other products release, the tentative plan is to have them go Scrum. Because there are shared components there will be a shared backlog for all three products. I don't think it's clear to anyone, even the 3 separate Product Owners how it's all going to work.

          Specific Questions
          1. Should there even be a shared backlog? Has anyone ever seen this work?

          2. What about shared UI? Anyone have experience working on different Scrums for different products yet having to collaborate with other UI Designers because of shared components? (Example: A Management Center where a Manager can turn on/off features for each of the products.) Tips for making this work???

          3. What if I want to make a big usability change to a shared area and my PO agrees. But the other designer and PO don't agree. Who wins?

          I'm pretty sure we'll figure it out. But was wondering if anyone else had the same going on. Like I say, it's going really well as the lone UI/UX designer for one product. Engineers and Product Owner and I are constantly talking, working quickly and getting the user stories done. But I'm worried about being slowed down when we have to reach concensus with the other designer and or other Product Owners.

          Thanks everyone!
          Carey





        • Patrick
          ... tackle ... component ... becomes the ... Can you elaborate some more on how you ve divided up your teams in order to make sure the shared backlog doesn t
          Message 4 of 4 , Jul 15, 2008
            > Yes. We use the shared backlog - we call it a key tasks board - to
            tackle
            > items that impact multiple teams - infrastucture upgrades, shared
            component
            > changes, etc. The team that picks up one of these backlog items
            becomes the
            > 'owner' of that item.

            Can you elaborate some more on how you've divided up your teams in
            order to make sure the shared backlog doesn't result in conflict over
            features or code segments?
          Your message has been successfully submitted and would be delivered to recipients shortly.