The introduction of Agile methods into the software development process began over a decade ago and with each passing year it has gained increasing popularity. What has not been proven to my satisfaction is that the increase in Agile methods adoption has been followed by an overall increase in successful product or project delivery in the marketplace, where time to revenue is the key metric, not time to shipping.
During the past decade the UX community has evolved (and struggled) to fit UI design and user research deliverables within the short sprint-oriented time frames of Agile management models such as Scrum. Typical development sprints in the Scrum model are in the two to four week range with a one week evaluation and planning period in between each sprint. The HCI literature clearly documents the increased resource demand on designers that the Scrum process creates because of the daily meeting cycle to review details, issues, and code dependencies. The “just in time” service level that the development teams require generally means that a UI designer (and often a visual designer) must be assigned to each development team. Certainly a UI designer can’t support more than two different development teams concurrently.
Another issue that is generally overlooked in the deployment of Agile methods is the cost to UX of functional versus feature orientation when Agile is applied across multiple teams working on the same product. For example, if organized vertically—where each team codes a feature from database to UI design—then a development unit consisting of ten teams of ten people will require at least five UI designers (but more likely ten) because of the heavy overhead cost of coordinating UI consistency and integration. If development is organized horizontally by having just one of the Agile teams build 100 percent of the UI, then the UX load is reduced both in the daily meeting participation and also regarding coordination effort. I do not propose that this is a linear decrease because the coordination burden still tends to fall on the UX organization. However, the horizontal model may be the difference between making the project survivable for a team of five UX experts as opposed to a suicide mission.
The larger issue, and sorry truth, is that Agile methods, just like the previous variations of the waterfall development methods, is still subject to the garbage in, garbage out rule. If you start development without a clear product definition and set of requirements, you may rapidly produce an output of no real commercial value. Because Agile is never structured to start over at the end of the final sprint, from an economic perspective this is no better than a failed waterfall method.
One of the approaches applied to compensate for the short time frame boxing of Agile methods is to execute a Sprint Zero that focuses on requirements and design. This can be helpful to give the UX team a month to outline a high-level design before coding starts, but it is rarely sufficient on a product of any size. It is certainly not an adequate context in which to conduct user research.
In my opinion, the answer to this dilemma lies in redefining the phase before the traditional Agile development starts, to create a product definition phase that includes both user research and a high-level design. This phase can itself follow Agile methods, but needs to be decoupled from the official development sprints. In fact, completing this pre-phase should become a funding gate that cannot be crossed without executive signoff before real coding efforts begin.
Detailed UI design can precede one or more sprints ahead of development with some allotment for just-in-time corrections. But if the high-level UI design and information architecture (IA) are not available in advance, all we are doing is helping our host development organization fail sooner. It is time we took a responsible stand on this issue instead of claiming we have arrived at UX maturity models that are totally compatible with Agile as many have argued. If we honestly measure based on product success and not Scrum process timeline adherence, there is plenty of evidence to suggest that the garbage in, garbage out rule still compromises our professional contribution on a daily basis.
