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

4026Re: [agile-usability] Re: Leverage a small UX team?

Expand Messages
  • Jon Dickinson
    Feb 4 12:07 PM
    • 0 Attachment
      I would be tempted to move Scrum Masters higher on the list. While I think you are right to target product owners first, as they should get the final say on what goes into their product, Scrum Masters should be working closely with the product owners so they have an idea of what is coming up for the next sprint. These people also have the respect of the development team as it is their job to make the teams life easier. It will be useful to build relationships with Scrum Masters early on to figure out how you can fit the UX activities into the sprint cycle.

      I like your idea of building UX into the sprint exit criteria. Do you have any ideas how you are going to achieve this yet?


      On 04/02/2008, timkieschnick <tim.kieschnick@...> wrote:

      Thanks for the good advice. I'm clearly not going to get another
      dozen UX specialists, so I need to leverage my 4 specialists across
      the people in the dedicated teams. Here's what I'm thinking in terms
      of training priorities:

      First, Product Owners:
      - evangelize them on user experience
      - introduce them to the core toolset and the support available
      - think together about how to build UX into the product backlog and
      sprint exit criteria
      - work with them on an ongoing shared product backlog for things
      like creating and implementing design patterns or templates across
      the site

      Second, Business Analysts:
      - evangelize--give them something to live for to replace the
      requirements documents they've been lost in for the last 3 years
      - introduce them to the core toolset and the support available
      - give them the hands-on skills to do things like user-centered
      stories, effective use of personas, and card sorts

      Third, Everybody Else:
      At this point I'll have a skeleton of a support system in place, and
      two people on each team who can tangibly make use of general
      excitement about the user experience.
      - evangelize
      - UX and the product lifecylce
      - when to call for help

      Fourth, Scrummasters:
      - collaborative working session to come up with some shared best
      practices and places to innovate

      Having not done scrum yet myself, I'm probably front-loading too
      much. There will certainly be plenty of informal alignment &
      education going on, but how does this look for the formal training

      --- In agile-usability@yahoogroups.com, Adrian Howard <adrianh@...>

      > On 31 Jan 2008, at 09:45, Manish Pillewar wrote:
      > [snip]
      > > >> 3) We're thinking that the best times to bring in the UX
      > > specialists are
      > > >> (a) project inception, prior to forming the team, to help
      > > initial
      > > >> user research (ethnography, persona development, etc.) and
      > > during
      > > >> release planning (or maybe between each sprint), to help
      > > team ID
      > > >> what tools from the world of user-centered design will be
      > > helpful
      > > >> for the coming work, and how the UX team can support that.
      > >
      > > This is perfect. You can also choose to involve the designers
      > > POC activities or use their creativity to conceptulize UI
      > > during sales pitches or/and do competitive benchmarking
      > > as a showcase of Ux capabilities. QA is one more arena where
      > > designer can help in. She can do design reviews or usability
      > > evaluations( heuristics,etc), even quick usability testing on
      > > developed screens at every iteration end, to ensure that the UX
      > > standards are maintained.
      > [snip]
      > Not sure that I'd describe it as perfect :-)
      > I find that you get a _lot_ more value by having UX folk involved
      > with the team as close to 100% as possible. While there is
      > a lot "big" UX work that sits on the customer side, communicating
      > is much better done in person than with documents. There are also
      > always UX issues that pop up during development. Having a UX
      > on-hand makes sure that they'll be addressed in an appropriate
      > So my perfect set up has at least one UX person as a member of
      > team 100% of the time.
      > Which of course sucks as a solution if, like the OP, you only
      > UX folk than development teams...
      > Assuming that hiring a bunch more UX dudes isn't practical, I'd
      > looking at spending a lot more time in general education of the
      > team in UX issues. That way there's more chance that UX issues
      > pop up mid-iteration are handled well (even/especially when the
      > method is "get a UX dude here stat" :-)
      > Cheers,
      > Adrian

    • Show all 21 messages in this topic