7230Re: Integrated Usability in Agile teams from the trenches :)
- Feb 3, 2011Thank you very much for sharing your experience. It is very useful. The comment about iRise made me smile :-) Let me shake your hand, comrade.
--- In firstname.lastname@example.org, Robin Dymond <robin.dymond@...> wrote:
> I recently replied to someone on linked in who was having trouble
> integrating UX people into an Agile team. Below is my step by step reply on
> how to do UX in an Agile manner. I'd be interested in hearing your thoughts
> on this pattern.
> I was a technology Director in a large web design company 6 years ago, and
> they failed at adopting Agile for the reasons you mention. Primarily it was
> a case of not wanting reality to hinder the pretty designs they were making
> in photoshop or Illustrator. Of course there were huge issues when these
> artifacts met the reality of enterprise architectures on the development
> floor. This resulted in missed deadlines, high stress, low code quality, and
> 40% annual turnover in IT staff. Being at this company spurred my interest
> in UX and Agile, and I have since found basic solutions that work when
> people want to do Agile. However I would say that of all the disciplines in
> creating software and especially web sites, UX people are the slowest and
> most resistant to adopting Agile principles and practices.
> Here is the way I work with UI designers and Information architects who want
> to work Agile:
> 1. Product backlog and its priorities drives all the work. So we work from
> business priorities not UI priorities.
> 2. Sketch the highest level level UI for the site. no drill downs into buy
> flows, just top level.
> 3. Look at the backlog and start thinking about what the team will need for
> UI 1/2 an iteration ahead.
> 4. Make paper prototypes (sketches, paper menus, paper buttons) to support
> upcoming user stories for next sprint. Don't embellish with new features UX
> thinks would be cool. KISS. Include validation and other acceptance criteria
> for fields. Reference style guide as required. Reference page templates as
> required. I call this a 1 page design spec.
> 5. Review prototypes with PO, QA and lead dev a few days before sprint
> planning, ensure they think it is good enough and it is testable. Keep notes
> regarding potential trade offs.
> 5a. Check in design docs, version them.
> 6. Participate in sprint planing with rest of team.
> 7. Work with team on implementation, clarify details of design (dimensions,
> locations, behavior, etc.). Work with QA on test plans for new UI. Help
> build UI (HMTL/CSS/PHP/etc) in dev IDE, pair with dev as they wire it up.
> Pair with QA to run test cases and implement automated UI testing
> (Ruby/WATIR, etc).
> 8. repeat for every sprint.
> Additional stuff I think is needed.
> - Create a style guide for the team and have them read it, listen to their
> feedback and improve it.
> - Create templates: every page is not a unique creation. Refer to those
> templates in prototypes and design spec.
> - Test your paper prototypes with users by asking them to do certain
> operations and then observing the resulting actions. Don't worry about big
> usability testing at end, do it often and informally with people who are
> easy to access and know enough about that business.
> - Break dependencies between UI/layout and business logic. agree on
> data/fields/controls at beginning so business logic can be rendered to a
> very simple layout free page.
> An unstable UI design is usually driven by a lack of knowledge about the
> customer requirements and technical limitations. The product backlog is
> probably not in very good shape so the UI person has to go find out a lot of
> detail to create the design. The UI designer is likely having to make up for
> lack knowledge in the PO.
> ...and avoid iRise and its ilk!!!
> I hope this helps,
> Robin Dymond. CST
- << Previous post in topic Next post in topic >>