[IxDA Discuss] UCD and Agile Programming - models of involvement

[Jim Drew]

>From: Mimi Knowles <mknowles at limina-ao.com>
>
>1.	On one project, the usability team would always be an iteration
>ahead of the development team, creating storyboards and fleshing out
>interaction details to hand off to the development team when they were
>ready. During the development iteration, the usability team would continue
>supporting the actual development of the application while doing the
>storyboarding for the upcoming iteration.
>
>2.	On the other project, the usability team worked in tandem with the
>development team (same iteration at the same time), fleshing out design
>concepts at the same time as the developers were figuring out the technical
>details and coding. 
>
>I found the first method to be much more effective. Has anyone found a
>particular method of involvement that works particularly well?

As a software tester focusing on UI, I've worked on both sorts of projects, and I was miserable on the "agile" one.  Things never felt "solid": the Dev team would push things through from the UI team as fast as they could, but with no time able to be spent on revision cyclesfrom QA because the next stuff was being handed off to them.  The big fallout result was that bugs (both UI and lesser functionality) which would normally have had a "bake time" and get dealt with were being deferred or discarded midway through the Alpha phase (with nearly a year left in the project) because there was no time to fix them.  Which indicates that scheduling and scoping was way out of whack by the time we got the first versions of the software to test.

The two things most missing on that project from the QA side were:

* While UI and Dev had an "agile" plan in place, QA did not.  (I don't know if that'sm ineptitude by the QA managers, not realizing what they needed to do, or QA being left ot of the loop in the decision making and not knowing that the need for such plan would come.)  QA had to struggle with trying to bridge traditional test methods and scheduling into the "agile" scheme; running as fast as we could just to stay in place.

* What spec review was being done prior to hand-off to develeopment was being done purely by the management team (include QA managers), not by the test engineers who would actually be working with the software.  And thus the mid and low level interaction details were never questioned and never specified, leaving the answer to QA's "what should it do when?" questions being "try it and find out".  (And the response to "it doesn't work right" being "too bad, that's what's in the spec".)


In the end, "agile" development and other mechanisms meant to cut through process slowdown(*) only work if you have buy-in and understanding from everyone involved.  Not just the managers but all the people who will be working day in and day out on the process.


(*) We also used a spec driving process which identified approval roles, usually narrowing things down to an initiator, and couple other people who got to "vote", and two larger groups of people who would be informed and should be (but generally were not) informed.  Intended to reduce the need for consensus from a groups of 6-12 people, it also allowed for shutting down of discussion and debate.  QA was never in a voting position, and individual QA engineers were never in the "must be informed" set.  Ergo, features and designs were approved without input from the people who needed the info.


-- Jim Drew
    Seattle, WA