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

Spread too thin??

Expand Messages
  • j_cabinaw
    Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand
    Message 1 of 13 , Mar 4, 2010
      Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand for UX services from my team rises (a good thing!) our ability to be spread across multiple agile project teams is wearing the team out and making them feel like a casualty of agile and processes that leave us out because there is not enough of us to go around. (a bad thing!) We are only one deep in interaction design and visual design (in the process of trying to find a new person with visual and intearctive design competencies...but still quite thinly resourced.)

      At any given time, there may be 4-5 agile projects underway (or more) and my team members have to participate in scrums for all these teams, meetings for all these teams, and still manage to do the work. Its a major burnout factor. In addition, it is hard to maintain a higher level organizational visibility of the capacity of my team to ensure we prioritize their time to the most important projects. I spend a tone of time managing this via Microsoft TFS to keep a higher level visibility of this.

      In any case, would love to hear if anyone else has been there, done that and how you solved this conundrum?
    • William Pietri
      ... I don t have any magic solutions, but I did want to tell you that this is a common problem. A good Agile adoption should increase development output, make
      Message 2 of 13 , Mar 4, 2010
        On 03/04/2010 12:09 PM, j_cabinaw wrote:
        > Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand for UX services from my team rises (a good thing!) our ability to be spread across multiple agile project teams is wearing the team out and making them feel like a casualty of agile and processes that leave us out because there is not enough of us to go around. (a bad thing!) We are only one deep in interaction design and visual design (in the process of trying to find a new person with visual and intearctive design competencies...but still quite thinly resourced.)
        >

        I don't have any magic solutions, but I did want to tell you that this
        is a common problem.

        A good Agile adoption should increase development output, make the need
        for UX help more obvious, and increase the frequency with which teams
        can apply UX skills. All of which are definitely good things, but, as
        you say, with consequences. The main upside of your situation is that in
        an Agile context, you should eventually be able to invest less time in
        expensive design artifacts.

        The companies I see doing best at this have a designer (or more)
        assigned to each team, embedded within it. That person may not be able
        to do everything themselves, but they handle what the can, get
        intimately involved with the project, and know when and how to involve
        other designers in the company. Trulia and YouTube are two examples of
        that where I know the designers are happy.

        When there aren't enough designers to go around, the most common
        adaptations I see are spreading designers too thin, letting average
        design quality decline, and having the most design-oriented person on
        the team act as in-house designer and bridge to the UX group.

        Forced to pick one, I'd go with the last, because then the problem is at
        least obvious. But mainly I'd hire more designers.

        William
      • Marius van Dam
        Hi, Of course the best would be if ux resources would be part of the teams but you lack the resources. Look like you have to organise your capacity in a lean
        Message 3 of 13 , Mar 4, 2010
          Hi,

          Of course the best would be if ux resources would be part of the teams
          but you lack the resources.

          Look like you have to organise your capacity in a lean way. Maybe have
          a look at kanban and put up the requests from various teams as cards.
          A max number of cards can pass through your process and thus
          management will need to prioritise.

          another idea could be to coach and guide the actual team members to
          produce better ux themselves.

          Good luck!

          2010/3/4, j_cabinaw <julie@...>:
          > Would love to hear from some of you on this issue – I manage a UX team that
          > is in an agile driven organization, has been for 2-3 years now. As the
          > demand for UX services from my team rises (a good thing!) our ability to be
          > spread across multiple agile project teams is wearing the team out and
          > making them feel like a casualty of agile and processes that leave us out
          > because there is not enough of us to go around. (a bad thing!) We are only
          > one deep in interaction design and visual design (in the process of trying
          > to find a new person with visual and intearctive design competencies...but
          > still quite thinly resourced.)
          >
          > At any given time, there may be 4-5 agile projects underway (or more) and my
          > team members have to participate in scrums for all these teams, meetings for
          > all these teams, and still manage to do the work. Its a major burnout
          > factor. In addition, it is hard to maintain a higher level organizational
          > visibility of the capacity of my team to ensure we prioritize their time to
          > the most important projects. I spend a tone of time managing this via
          > Microsoft TFS to keep a higher level visibility of this.
          >
          > In any case, would love to hear if anyone else has been there, done that and
          > how you solved this conundrum?
          >
          >

          --
          Verzonden vanaf mijn mobiele apparaat

          Met vriendelijke groet,

          Marius van Dam
          ---
          mariusvandam@...
        • Anders Ramsay
          One approach to addressing this is UX Office Hours, in which each team produces ux/ui solutions without a ux specialist or with minimal involvement, and can
          Message 4 of 13 , Mar 4, 2010
            One approach to addressing this is UX Office Hours, in which each team
            produces ux/ui solutions without a ux specialist or with minimal
            involvement, and can then have ux specialists available during
            rhythmic office hours to review, provide feedback and facilitate an
            overall consistent vision/concept.

            This allows the team to own the ux and a smaller number of specialists
            to oversee a larger range of work.

            -Anders

            Sent from my iPhone

            On Mar 4, 2010, at 4:47 PM, Marius van Dam <mariusvandam@...>
            wrote:

            > Hi,
            >
            > Of course the best would be if ux resources would be part of the teams
            > but you lack the resources.
            >
            > Look like you have to organise your capacity in a lean way. Maybe have
            > a look at kanban and put up the requests from various teams as cards.
            > A max number of cards can pass through your process and thus
            > management will need to prioritise.
            >
            > another idea could be to coach and guide the actual team members to
            > produce better ux themselves.
            >
            > Good luck!
            >
            > 2010/3/4, j_cabinaw <julie@...>:
            >> Would love to hear from some of you on this issue – I manage a UX
            >> team that
            >> is in an agile driven organization, has been for 2-3 years now. As
            >> the
            >> demand for UX services from my team rises (a good thing!) our
            >> ability to be
            >> spread across multiple agile project teams is wearing the team out
            >> and
            >> making them feel like a casualty of agile and processes that leave
            >> us out
            >> because there is not enough of us to go around. (a bad thing!) We
            >> are only
            >> one deep in interaction design and visual design (in the process of
            >> trying
            >> to find a new person with visual and intearctive design
            >> competencies...but
            >> still quite thinly resourced.)
            >>
            >> At any given time, there may be 4-5 agile projects underway (or
            >> more) and my
            >> team members have to participate in scrums for all these teams,
            >> meetings for
            >> all these teams, and still manage to do the work. Its a major
            >> burnout
            >> factor. In addition, it is hard to maintain a higher level
            >> organizational
            >> visibility of the capacity of my team to ensure we prioritize their
            >> time to
            >> the most important projects. I spend a tone of time managing this
            >> via
            >> Microsoft TFS to keep a higher level visibility of this.
            >>
            >> In any case, would love to hear if anyone else has been there, done
            >> that and
            >> how you solved this conundrum?
            >>
            >>
            >
            > --
            > Verzonden vanaf mijn mobiele apparaat
            >
            > Met vriendelijke groet,
            >
            > Marius van Dam
            > ---
            > mariusvandam@...
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
          • Preston
            HI I saw your post: And I know your pain. I have written several articles on my blog about agile and ux - uidesignguide.com. I think you have to look at this
            Message 5 of 13 , Mar 5, 2010
              HI I saw your post:

              And I know your pain.

              I have written several articles on my blog about agile and ux - uidesignguide.com.

              I think you have to look at this at a different approach.I've worked in the same situation and even situations where waterfall method is primarily used. Ultimately, you have to have people that can multi-task and are empowered to attend the meetings as YOU as a UX team need them and decline those that are not required for the UX to attend,

              Are your scrums running too long?
              a scrum should be no more than 15 minutes a day. Even with 3 people and 1 person attending 4 - 5 design meetings. That's not too bad to manage time wise. [ I've worked on 4 upwards of 6 projects at once doing UX solo for many years.]

              What this means is you need to adapt your practices as a UX professional. Use rapid prototyping [ wire frames, paper, ] to rapidly illustrate designs, interactions, and workflows. Use interactive PDF's or quick prototyping tools, axure, balsamiq, flex builder, etc... You can accomplish quite a lot this way, before a sprint or iteration even begins. Also you don't feel put out if something is prioritized lower or thrown out entirely. You can start lift some of the team burden.

              You could also take a look and, I talk about this at my web site, At having your team control different stages of the cycle on different projects. For example 1 team member works in the future [ 2 weeks ahead of core development] and works on rough drafts, paper designs, light wire frames for upcoming stories.

              Another team member can work on quality assurance or the "future" of the product, after design / coding / ux have come together to produce a "done" state product.

              And another can live in the present - taking the day to day activities scrums, etc, and relaying them to the team, working on the implementation of the design across the various projects and setting up meetings to inform other UX team members what should be done, or what needs to be accomplished and start setting timelines within your functional group.

              A lot of this will depend on the makeup of your team, but it can be done and there are going to be stressful times, but that is true with any work.

              So how can you go about doing this.

              1. In your next retrospective take a look at your existing successes, and problems for the UX team and truly get into what is causing them.

              Is it the process, lack of resources, lack of time, lack of product owner support, flaky stories,

              2. Next take a look at how these is helping / hurting the team.
              In some cases scrums may be lasting 40 minutes, when breakout meetings should be held. I know I don't necessarily hang around for database / data structuring meetings.

              3. Take a look at and determine are you finishing your sprints/iterations? If so at what cost to the teams? Do things feel rushed? Are you completing a "done" state a the very end of your cycle so rushed to move to next?

              Is your teams design time factored in if you are using task planning? Are you forced to do a process to satisfy a group? If you are then there is a big issue.

              4. Does it seem like stories are not freezing or being time boxed correctly? Are you preparing a little bit ahead and reading stories that are upcoming? Are you preparing too much ahead and having to toss stuff. - This can really help to identify problems from a technical / design hurdle up front, but just enough and that is what you need to figure out.

              5. Is the product being delivered or is it suffering in some way? does it feel like the groups definition of "done" is too rigid / not rigid enough?

              6. Has the development team made it easy for the UX group to adapt to the program code for your implementors.

              7. Are your iterations / sprints too short?

              Theses are just a few questions I would really take a look at to start. Just like the agile process for development you need to refine the core process for each team. Other wise the stress levels go way up and the product owners become unhappy not too mention the team.

              Solve dysfunctions in the process, product, and keep doing your retrospective. A lot of times these just drop off to the wayside and they are really needed to help you reach the next level of greatness.

              Preston M

              http://www.uidesignguide.com
              http://www.uidesignguide.com/2009/10/20/ui-design-lessons-a-ui-designer-in-an-agile-world-get-me-out-of-hell-part-1/

              --- In agile-usability@yahoogroups.com, "j_cabinaw" <julie@...> wrote:
              >
              > Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand for UX services from my team rises (a good thing!) our ability to be spread across multiple agile project teams is wearing the team out and making them feel like a casualty of agile and processes that leave us out because there is not enough of us to go around. (a bad thing!) We are only one deep in interaction design and visual design (in the process of trying to find a new person with visual and intearctive design competencies...but still quite thinly resourced.)
              >
              > At any given time, there may be 4-5 agile projects underway (or more) and my team members have to participate in scrums for all these teams, meetings for all these teams, and still manage to do the work. Its a major burnout factor. In addition, it is hard to maintain a higher level organizational visibility of the capacity of my team to ensure we prioritize their time to the most important projects. I spend a tone of time managing this via Microsoft TFS to keep a higher level visibility of this.
              >
              > In any case, would love to hear if anyone else has been there, done that and how you solved this conundrum?
              >
            • whyjg@yahoo.com
              Other than mitigating burn out (which is a serious concern for my team) how does spreading the team over so many projects (an issue I also face) affect quality
              Message 6 of 13 , Mar 5, 2010
                Other than mitigating burn out (which is a serious concern for my team) how does spreading the team over so many projects (an issue I also face) affect quality of work?

                Looking at Preston's suggestions leads me to believe that the end deliverable from UX can vary based on time and tool used BUT how does that account for the quality of the experiences being created?

                One of our current challenges is ensuring we create engaging, desirable and usable experiences yet the all-out speed of 2-week iterations generally leaves much of that deeper thinking by the wayside. Along the way we collect UX "debt" but in reality we rarely go back and pay down much of that debt.

                I've actually instructed my team to refuse a full iteration's worth of work if they can't commit to a quality bar by iteration's end. While solid in theory (in my opinion) it ends up making UX look "lazy" or not "team players". In addition it puts us in a situation where there isn't enough "ready" for the dev team to fill up available points.

                So....burn out and quality -- two risks of spreading the team thin. Any thoughts on mitigating?


                Thanks.

                [Jeff]

                Sent from my DeLorean at 88MPH


                From: "Preston" <imaginethepoet@...>
                Date: Fri, 05 Mar 2010 12:56:55 -0000
                To: <agile-usability@yahoogroups.com>
                Subject: [agile-usability] Re: Spread too thin??

                 

                HI I saw your post:

                And I know your pain.

                I have written several articles on my blog about agile and ux - uidesignguide. com.

                I think you have to look at this at a different approach.I've worked in the same situation and even situations where waterfall method is primarily used. Ultimately, you have to have people that can multi-task and are empowered to attend the meetings as YOU as a UX team need them and decline those that are not required for the UX to attend,

                Are your scrums running too long?
                a scrum should be no more than 15 minutes a day. Even with 3 people and 1 person attending 4 - 5 design meetings. That's not too bad to manage time wise. [ I've worked on 4 upwards of 6 projects at once doing UX solo for many years.]

                What this means is you need to adapt your practices as a UX professional. Use rapid prototyping [ wire frames, paper, ] to rapidly illustrate designs, interactions, and workflows. Use interactive PDF's or quick prototyping tools, axure, balsamiq, flex builder, etc... You can accomplish quite a lot this way, before a sprint or iteration even begins. Also you don't feel put out if something is prioritized lower or thrown out entirely. You can start lift some of the team burden.

                You could also take a look and, I talk about this at my web site, At having your team control different stages of the cycle on different projects. For example 1 team member works in the future [ 2 weeks ahead of core development] and works on rough drafts, paper designs, light wire frames for upcoming stories.

                Another team member can work on quality assurance or the "future" of the product, after design / coding / ux have come together to produce a "done" state product.

                And another can live in the present - taking the day to day activities scrums, etc, and relaying them to the team, working on the implementation of the design across the various projects and setting up meetings to inform other UX team members what should be done, or what needs to be accomplished and start setting timelines within your functional group.

                A lot of this will depend on the makeup of your team, but it can be done and there are going to be stressful times, but that is true with any work.

                So how can you go about doing this.

                1. In your next retrospective take a look at your existing successes, and problems for the UX team and truly get into what is causing them.

                Is it the process, lack of resources, lack of time, lack of product owner support, flaky stories,

                2. Next take a look at how these is helping / hurting the team.
                In some cases scrums may be lasting 40 minutes, when breakout meetings should be held. I know I don't necessarily hang around for database / data structuring meetings.

                3. Take a look at and determine are you finishing your sprints/iterations? If so at what cost to the teams? Do things feel rushed? Are you completing a "done" state a the very end of your cycle so rushed to move to next?

                Is your teams design time factored in if you are using task planning? Are you forced to do a process to satisfy a group? If you are then there is a big issue.

                4. Does it seem like stories are not freezing or being time boxed correctly? Are you preparing a little bit ahead and reading stories that are upcoming? Are you preparing too much ahead and having to toss stuff. - This can really help to identify problems from a technical / design hurdle up front, but just enough and that is what you need to figure out.

                5. Is the product being delivered or is it suffering in some way? does it feel like the groups definition of "done" is too rigid / not rigid enough?

                6. Has the development team made it easy for the UX group to adapt to the program code for your implementors.

                7. Are your iterations / sprints too short?

                Theses are just a few questions I would really take a look at to start. Just like the agile process for development you need to refine the core process for each team. Other wise the stress levels go way up and the product owners become unhappy not too mention the team.

                Solve dysfunctions in the process, product, and keep doing your retrospective. A lot of times these just drop off to the wayside and they are really needed to help you reach the next level of greatness.

                Preston M

                http://www.uidesign guide.com
                http://www.uidesign guide.com/ 2009/10/20/ ui-design- lessons-a- ui-designer- in-an-agile- world-get- me-out-of- hell-part- 1/

                --- In agile-usability@ yahoogroups. com, "j_cabinaw" <julie@...> wrote:
                >
                > Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand for UX services from my team rises (a good thing!) our ability to be spread across multiple agile project teams is wearing the team out and making them feel like a casualty of agile and processes that leave us out because there is not enough of us to go around. (a bad thing!) We are only one deep in interaction design and visual design (in the process of trying to find a new person with visual and intearctive design competencies. ..but still quite thinly resourced.)
                >
                > At any given time, there may be 4-5 agile projects underway (or more) and my team members have to participate in scrums for all these teams, meetings for all these teams, and still manage to do the work. Its a major burnout factor. In addition, it is hard to maintain a higher level organizational visibility of the capacity of my team to ensure we prioritize their time to the most important projects. I spend a tone of time managing this via Microsoft TFS to keep a higher level visibility of this.
                >
                > In any case, would love to hear if anyone else has been there, done that and how you solved this conundrum?
                >

              • George Dinwiddie
                Julie, You ve already received some excellent advice, but I d like to focus on one small bit. ... Are your team members receiving value from all of these
                Message 7 of 13 , Mar 5, 2010
                  Julie,

                  You've already received some excellent advice, but I'd like to focus on
                  one small bit.

                  j_cabinaw wrote:
                  > At any given time, there may be 4-5 agile projects underway (or more)
                  > and my team members have to participate in scrums for all these
                  > teams, meetings for all these teams, and still manage to do the work.

                  Are your team members receiving value from all of these meetings? Are
                  they providing value for all of these meetings?

                  It could be that they only need to attend some of them. It also could
                  be that there are too many meetings, or they're not well focused. Or
                  any of a number of other problems that meetings often have.

                  I suggest that having a retrospective with your team members might turn
                  up some insights and possibly some actions you can take.

                  - George

                  --
                  ----------------------------------------------------------------------
                  * George Dinwiddie * http://blog.gdinwiddie.com
                  Software Development http://www.idiacomputing.com
                  Consultant and Coach http://www.agilemaryland.org
                  ----------------------------------------------------------------------
                • Austin Govella
                  ... It kills quality, but you re able to help the organization release a product that s not as bad as what would go out without UX there. Faint praise, but if
                  Message 8 of 13 , Mar 5, 2010
                    On Fri, Mar 5, 2010 at 7:54 AM, <whyjg@...> wrote:
                    > Other than mitigating burn out (which is a serious concern for my team)
                    > how does spreading the team over so many projects (an issue I also face)
                    > affect quality of work?

                    It kills quality, but you're able to help the organization release a
                    product that's not as bad as what would go out without UX there. Faint
                    praise, but if that gets you by...

                    You can avoid the total mediocrity by taking all the typical advice:

                    1. Do everything you can to boost the organization's design literacy.
                    The better the org is, the less bad the non-UXd product will be,
                    spreading you less thin over time.

                    2. Find allies. Some engineers and product managers have better UX
                    skills than others, or are more amenable to your advice. These are
                    people you can spend less time with and still achieve the same results
                    you achieve with more effort elsewhere.

                    3. Cherry pick projects. Find projects where you can have a really
                    good impact, hit these projects out of the park. This requires before
                    and after measurement of some sort (even if they're just ad hoc
                    heuristics). It also requires closer than normal work with the team
                    (to ensure implementation matches design). And when these projects are
                    successes, mention it at every single meeting for a fucking year.

                    One whole year.

                    (And when they fail, examine why, fix it, and pick the next project.)



                    --
                    Austin Govella
                    User Experience

                    Work: http://www.grafofini.com
                    Blog: http://www.thinkingandmaking.com
                    Book: http://www.blueprintsfortheweb.com

                    austin@...
                    215-240-1265
                  • Preston
                    Good point Quality is only going to be as good as long as your ux team can handle the load. Some times the best you can do in real situations like corporate
                    Message 9 of 13 , Mar 5, 2010
                      Good point

                      Quality is only going to be as good as long as your ux team can handle the load. Some times the best you can do in real situations like corporate environments is guide the team. It's not going to fully get you the best product and that's sad but true.

                      A lot of times start-ups are where you will get a lot of the best products because the product owner can control the product and vision so close.

                      Your product is only going to be as good as your weakest link. Whether that be time, money, resources, etc..

                      When I look at the UX process as a whole in relation to agile you have to be flexible and take a look at what is reality. We all want the greatest products and the greatest experience. Especially true if you are a interaction designer, but it just doesn't always happen.

                      That is the nature of the beast. Agile for ux is about rapid design, but you can also figure ways to implement rapid usability testing,

                      Keep in mind the state of "done" could just mean done for this iteration, in all hopes you will refine that piece of application and have time to refine the design. Does it happen? Not as often as I would like to see.

                      All I can provide is tips that I know work, I use them. I practice them and most important I adjust theme.

                      As the cycle becomes more rapid, quality can suffer, but then when it does you have to figure out how can you fix it? How can you do this as a team? Sometimes you might have to rely on your other team members to take on roles. That is when you have to be prepared to give expert guidance.



                      --- In agile-usability@yahoogroups.com, whyjg@... wrote:
                      >
                      > Other than mitigating burn out (which is a serious concern for my team) how does spreading the team over so many projects (an issue I also face) affect quality of work?
                      >
                      > Looking at Preston's suggestions leads me to believe that the end deliverable from UX can vary based on time and tool used BUT how does that account for the quality of the experiences being created?
                      >
                      > One of our current challenges is ensuring we create engaging, desirable and usable experiences yet the all-out speed of 2-week iterations generally leaves much of that deeper thinking by the wayside. Along the way we collect UX "debt" but in reality we rarely go back and pay down much of that debt.
                      >
                      > I've actually instructed my team to refuse a full iteration's worth of work if they can't commit to a quality bar by iteration's end. While solid in theory (in my opinion) it ends up making UX look "lazy" or not "team players". In addition it puts us in a situation where there isn't enough "ready" for the dev team to fill up available points.
                      >
                      > So....burn out and quality -- two risks of spreading the team thin. Any thoughts on mitigating?
                      >
                      >
                      > Thanks.
                      >
                      > [Jeff]
                      > Sent from my DeLorean at 88MPH
                      >
                      > -----Original Message-----
                      > From: "Preston" <imaginethepoet@...>
                      > Date: Fri, 05 Mar 2010 12:56:55
                      > To: <agile-usability@yahoogroups.com>
                      > Subject: [agile-usability] Re: Spread too thin??
                      >
                      > HI I saw your post:
                      >
                      > And I know your pain.
                      >
                      > I have written several articles on my blog about agile and ux - uidesignguide.com.
                      >
                      > I think you have to look at this at a different approach.I've worked in the same situation and even situations where waterfall method is primarily used. Ultimately, you have to have people that can multi-task and are empowered to attend the meetings as YOU as a UX team need them and decline those that are not required for the UX to attend,
                      >
                      > Are your scrums running too long?
                      > a scrum should be no more than 15 minutes a day. Even with 3 people and 1 person attending 4 - 5 design meetings. That's not too bad to manage time wise. [ I've worked on 4 upwards of 6 projects at once doing UX solo for many years.]
                      >
                      > What this means is you need to adapt your practices as a UX professional. Use rapid prototyping [ wire frames, paper, ] to rapidly illustrate designs, interactions, and workflows. Use interactive PDF's or quick prototyping tools, axure, balsamiq, flex builder, etc... You can accomplish quite a lot this way, before a sprint or iteration even begins. Also you don't feel put out if something is prioritized lower or thrown out entirely. You can start lift some of the team burden.
                      >
                      > You could also take a look and, I talk about this at my web site, At having your team control different stages of the cycle on different projects. For example 1 team member works in the future [ 2 weeks ahead of core development] and works on rough drafts, paper designs, light wire frames for upcoming stories.
                      >
                      > Another team member can work on quality assurance or the "future" of the product, after design / coding / ux have come together to produce a "done" state product.
                      >
                      > And another can live in the present - taking the day to day activities scrums, etc, and relaying them to the team, working on the implementation of the design across the various projects and setting up meetings to inform other UX team members what should be done, or what needs to be accomplished and start setting timelines within your functional group.
                      >
                      > A lot of this will depend on the makeup of your team, but it can be done and there are going to be stressful times, but that is true with any work.
                      >
                      > So how can you go about doing this.
                      >
                      > 1. In your next retrospective take a look at your existing successes, and problems for the UX team and truly get into what is causing them.
                      >
                      > Is it the process, lack of resources, lack of time, lack of product owner support, flaky stories,
                      >
                      > 2. Next take a look at how these is helping / hurting the team.
                      > In some cases scrums may be lasting 40 minutes, when breakout meetings should be held. I know I don't necessarily hang around for database / data structuring meetings.
                      >
                      > 3. Take a look at and determine are you finishing your sprints/iterations? If so at what cost to the teams? Do things feel rushed? Are you completing a "done" state a the very end of your cycle so rushed to move to next?
                      >
                      > Is your teams design time factored in if you are using task planning? Are you forced to do a process to satisfy a group? If you are then there is a big issue.
                      >
                      > 4. Does it seem like stories are not freezing or being time boxed correctly? Are you preparing a little bit ahead and reading stories that are upcoming? Are you preparing too much ahead and having to toss stuff. - This can really help to identify problems from a technical / design hurdle up front, but just enough and that is what you need to figure out.
                      >
                      > 5. Is the product being delivered or is it suffering in some way? does it feel like the groups definition of "done" is too rigid / not rigid enough?
                      >
                      > 6. Has the development team made it easy for the UX group to adapt to the program code for your implementors.
                      >
                      > 7. Are your iterations / sprints too short?
                      >
                      > Theses are just a few questions I would really take a look at to start. Just like the agile process for development you need to refine the core process for each team. Other wise the stress levels go way up and the product owners become unhappy not too mention the team.
                      >
                      > Solve dysfunctions in the process, product, and keep doing your retrospective. A lot of times these just drop off to the wayside and they are really needed to help you reach the next level of greatness.
                      >
                      > Preston M
                      >
                      > http://www.uidesignguide.com
                      > http://www.uidesignguide.com/2009/10/20/ui-design-lessons-a-ui-designer-in-an-agile-world-get-me-out-of-hell-part-1/
                      >
                      > --- In agile-usability@yahoogroups.com, "j_cabinaw" <julie@> wrote:
                      > >
                      > > Would love to hear from some of you on this issue – I manage a UX team that is in an agile driven organization, has been for 2-3 years now. As the demand for UX services from my team rises (a good thing!) our ability to be spread across multiple agile project teams is wearing the team out and making them feel like a casualty of agile and processes that leave us out because there is not enough of us to go around. (a bad thing!) We are only one deep in interaction design and visual design (in the process of trying to find a new person with visual and intearctive design competencies...but still quite thinly resourced.)
                      > >
                      > > At any given time, there may be 4-5 agile projects underway (or more) and my team members have to participate in scrums for all these teams, meetings for all these teams, and still manage to do the work. Its a major burnout factor. In addition, it is hard to maintain a higher level organizational visibility of the capacity of my team to ensure we prioritize their time to the most important projects. I spend a tone of time managing this via Microsoft TFS to keep a higher level visibility of this.
                      > >
                      > > In any case, would love to hear if anyone else has been there, done that and how you solved this conundrum?
                      > >
                      >
                    • Anders Ramsay
                      ... Maybe I m not understanding this correctly, but this seems to imply that developers are helpless without the god-like vision of the ux team, that a quality
                      Message 10 of 13 , Mar 5, 2010
                        On Fri, Mar 5, 2010 at 4:09 PM, Preston <imaginethepoet@...> wrote:
                         

                        Quality is only going to be as good as long as your ux team can handle the load. Some times the best you can do in real situations like corporate environments is guide the team. It's not going to fully get you the best product and that's sad but true.

                        Maybe I'm not understanding this correctly, but this seems to imply that developers are helpless without the god-like vision of the ux team, that a quality user experience can only be achieved by the "ux team" (which seems to imply some separate ux dept) and not by other team members, and that without their involvement, a quality product simply cannot be achieved.
                         
                        In fact, I'd say that guiding the design of the ux, not doing the design separately in some UX dept, is what a UX specialist *should* be doing, and that this is a more effective way to deliver a quality product.  Here, the *the team* owns and is responsible for the UX, here developers are *actively* engaged in the UX design, rather than passive recipients of some design concept coming from on high.

                        -Anders
                      • pauloldfield1
                        (responding to Julie) ... We solved a similar but more severe problem - one person had 3 times the amount of work he could cope with, across several teams.
                        Message 11 of 13 , Mar 8, 2010
                          (responding to Julie)

                          > In any case, would love to hear if anyone else has been there,
                          > done that and how you solved this conundrum?

                          We solved a similar but more severe problem - one person had
                          3 times the amount of work he could cope with, across several
                          teams.

                          What we did: This one person did not do ANY of the work; all the
                          work was done by (in our case) 6 other people. This one expert
                          visited all the others in a more or less "round-robin" fashion,
                          advising, showing them how, keeping them on track, explaining
                          and correcting mistakes.

                          This approach worked really well for us; we never had a crisis of
                          skills shortage in that area again.

                          Paul Oldfield
                          Capgemini
                        • Glen B. Alleman
                          Paul, The vast percentage of our triage efforts for project and programs, from large defense to agile development start with building a RAM (Responsibility
                          Message 12 of 13 , Mar 8, 2010
                            Paul,

                            The vast percentage of our "triage" efforts for project and programs, from
                            large defense to agile development start with building a RAM (Responsibility
                            Assignment Matrix) - "who is doing what." Next is the assessment for
                            "capacity for work," - how much time does each person in the RAM have to
                            produce value for the project.

                            With this Big Visible Chart hanging on the wall, the majority of the issues
                            you talk about are no visible and their corrections actionable.

                            Glen Alleman

                            -----Original Message-----
                            From: agile-usability@yahoogroups.com
                            [mailto:agile-usability@yahoogroups.com] On Behalf Of pauloldfield1
                            Sent: Monday, March 08, 2010 3:51 AM
                            To: agile-usability@yahoogroups.com
                            Subject: [agile-usability] Re: Spread too thin??

                            (responding to Julie)

                            > In any case, would love to hear if anyone else has been there,
                            > done that and how you solved this conundrum?

                            We solved a similar but more severe problem - one person had
                            3 times the amount of work he could cope with, across several
                            teams.

                            What we did: This one person did not do ANY of the work; all the
                            work was done by (in our case) 6 other people. This one expert
                            visited all the others in a more or less "round-robin" fashion,
                            advising, showing them how, keeping them on track, explaining
                            and correcting mistakes.

                            This approach worked really well for us; we never had a crisis of
                            skills shortage in that area again.

                            Paul Oldfield
                            Capgemini




                            ------------------------------------

                            Yahoo! Groups Links
                          • j_cabinaw
                            I just wanted to say thank you for all the responses. I am sharing them with my team as fodder for a team discussion to aid in our problem solving. Also great
                            Message 13 of 13 , Mar 11, 2010
                              I just wanted to say thank you for all the responses. I am sharing them with my team as fodder for a team discussion to aid in our problem solving.

                              Also great to see that the current issue of UX magazine deals with agile and UX -- very timely and great articles for team discussion.

                              I welcome more ideas! I'm sure we could all benefit.

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