--- In email@example.com, Austin Govella <austin.govella@...> wrote:
> On Tue, Dec 14, 2010 at 1:05 PM, lauren2miller <lauren2miller@...> wrote:
> > My company is moving to agile Scrum and I'm providing input on how to do user research moving forward. In particular, I'd like to suggest that we start doing usability testing alongside the Scrum sprints.... There is very strong executive support for changing over from the current waterfall process to an agile Scrum process with the hope of getting better quality products faster (per the usual).
> A couple quick points of advice:
> First, agile is not faster. It release smaller pieces. Smaller pieces
> take less time to build and can be completed more quickly, but if
> you're building the Great Wall of China, you still have to take the
> time to lay every single brick.
> Second, developers will need to book time to watch usability tests,
> review and decide on fixes, and implement the fixes. This reduces the
> amount of code they can write, but you can't fix the problems you find
> if they haven't set aside time to do so. RITE testing is usually the
> way to go.
> Third, get a bucket. In addition to time devs book for fixes, get X
> number of hours per sprint to use in a UX bucket. This time is not
> pre-planned and should be used exclusively as you see fit to fix
> things you find or to implement that unsexy code that's super
> important to the UX but not sexy enough to make it to the top of
> management's priority list. (Sounds scary, but usually the product
> manager LOVES this because it gives them wiggle room.)
> Fourth, at sprint planning, have the team sketch flows for each story
> with any user interface. And for important data or interaction
> screens, have them sketch the screens. You would assist and review in
> the planning meeting. (I firmly believe the vast majority of UX+agile
> problems arise can be avoided if everyone sketches everything
> Fifth, put your stuff on the walls so everyone can see it. This shows
> everyone what you do and teaches them how to do it themselves.
> Sixth, create broad site architectures, common interaction patterns,
> and personas. These are like guidelines so devs can figure things out
> for themselves instead of needing you to review everything.
> Seventh, identify your black knights and spend as much time working
> with them as possible.
> Austin Govella
> User Experience
> Work: http://www.grafofini.com
> Blog: http://www.thinkingandmaking.com
Your message has been successfully submitted and would be delivered to recipients shortly.
Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer.
We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.