The Generalizing (User Experience) Specialist
Agile brings a focus on the team as a unit and a lack of willingness to block, or plan for dependencies, around specialists. The term “generalizing specialists” describes the goal for agile team members to become less diversified in the key skills of producing quality software.
A recent heated thread on the Agile-Usability discussion list resulted in the suggestion that UX specialists work to increase the development team’s acumen in user experience design. While limited, this is something that is typically useful for a UX practicioner in any type of team.
I’ve had success using Jakob Nielsen’s usability heuristics as concise guidelines that help design dialogues and can seep into the skulls of coders. Here’s a slight re-casting of the wording for this purpose:
- Keep the user informed of system status
- Match the real world
- Keep the user in control
- Be consistent internally & externally
- Prevent user error
- Enable recognition, don’t require recall
- Provide shortcuts for flexibility and efficiency
- Keep the design minimal
- Enable recovery from error (barring #5)
- Provide help
While splitting specialists across development teams is an anti-pattern in Agile, it’s also the case that solid UX work involves time outside the team room. By frequently referencing these principles in design processes, teams I’ve worked with have learned to avoid the situation where I return and request rework for #9, #9, #9…
So paste that top 10 list into your favorite word processor and print it for your team wall.
Dave Nicolette
March 12th, 2009 at 4:00 pm
I like your list. I think it would be very helpful for many teams.
Reviewing the discussion thread you mentioned, it struck me that the real problem in that case isn’t a question of generalizing specialists versus narrow-and-deep experts. The OP is describing an anti-pattern known as the Staggered Iterative Waterfall. This is a pattern in which a team attempts to work on three iterations simultaneously, with developers working on iteration n while analysts/designers work in iteration n+1 and testers work in iteration n-1.
One of the ideas of the iterative approach to agile work is that stories or MMFs (or whatever you call the work items) are completed in the same iteration as the one in which they are started. The problems the OP describes are characteristic of the Staggered Iterative Waterfall anti-pattern, and they are caused by the hard boundaries and hand-offs between the various specialized groups.
The crux of the problem is the time delay between the moment a decision is made and the moment a problem with that decision can be recognized. This particular anti-pattern forces that time to be at least two iterations, and often three. There is a rule of thumb that it takes about twice as long to fix a problem as it did to identify it; so, we are talking about problems that linger for 6 to 9 iterations. This can be a significant drag on the team’s throughput. When items have to be re-worked, the time spent on the re-work is lost to new value-add work.
This isn’t unique to UX, nor is it a problem with generalizing specialists, but is a general issue. The idea of generalizing specialists is that the majority of the work on a “typical” (yes, I know that’s a dangerous word) business application software development project doesn’t require the services of narrow-and-deep specialists in every discipline the project might touch upon. It doesn’t mean there is never a need for such specialists; it only means the team doesn’t need specialists on board full time every moment of the project. You overstate the case when you say agilists consider it an anti-pattern to engage experts at all.
General usability guidelines are well within the scope of a generalizing specialist. More specialized UX skills are not. We should use the skills and resources we need for each project, while taking care not to set up a process that creates needless waste.