imminent

Agile is a hot term in the industry. So are terms like object oriented and web 2.0. And like those other terms, agileis frequently misunderstood or misused. Or it becomes a hammer in search of nails.In this article, design to refers to methods employed when creating a User eXperience, or UX. Things like concept development, interaction design and visual design. Engineeringmeans standard activities like architecture, development, testing and continuous integration – things that make up the activity of turning a UX design into a real user interface that a person can touch, or click, or swipe.I started out thinking mostly about design, engineering and process, but ended up considering the relationships between different processes and risk. Risks like running over time and over budget, or ending up with a product that doesn’t really express the key nuances of the UX design.

Getting agile

Agile methodology, fundamentally, assumes the ability to encapsulate work into small tasks – the agility comes from the high degree of granularity and the ability to reassess progress and change direction after a smallish amount of time. Agile methodology further assumes that these tasks can be prioritized. And, generally, it assumes that teams can compartmentalize the work into sprints, usually one to three weeks in duration.

In practice, tasks are extracted from user stories and sized via the use of story points, a point being an arbitrary unit, a convention that describes the ability of the team to consume work. For example, an item might be assigned the value of 10 story points, or a team may decide that they can consume 150 story points per sprint (their velocity). Once identified, the tasks are prioritized, then placed in the backlog, the queue from which new work is assigned.

An important point: an agile team pulls a sprint’s worth of work from the backlog at the beginning of a sprint – but any work arriving after a sprint has started is prioritized, placed on the backlog, and considered at the beginning of the next sprint. In short, no new work is added to a sprint once the sprint has started. This allows a team to develop accurate metrics around their ability to do the work, reduces randomization of team members, and generally preserves sanity. Risk is mitigated by the ability to assess progress in short intervals, to make course corrections quickly, and to reprioritize tasks as required.

UX design: holistic by nature

The mention of design often conjures up a process that is more fluid, more nimble, than engineering. But that fluidity can actually prevent design from lending itself to agile methods: designing a UX is essentially an holistic process, where any change in an interaction model may need to be integrated across all parts of a user story, or even the larger context of an epic, or collection of user stories. A large number of tasks may be identified within an epic – but it may not be appropriate to transfer those tasks to the engineering team until the entire epic is completely designed and frozen.  This can apply to visual design as well, where changes in branding, style or design language can have impacts across many parts of a design.

Indeed, that condition might extend to an entire collection of epics, or an entire application, or an entire suite of applications. The risk here is that assessment of progress against scope and schedule may only be possible after large amounts of work have been completed.

Keeping the loops small

While still contained within the design process, changes can be resolved within the design team. Once handed off to the engineering team, however, surfaced changes frequently need to be fed back to the design team for resolution:

The larger the loop, the more expensive the change, and the bigger the risk. And the loops are unpredictable, adding even more risk.

Waterfall as an alternative

Another development methodology, “waterfall”, requires that work items transition from one group to the next through a gate of sorts, where the implication is that the work being transferred is “cooked”, or “frozen”, or complete, essentially freezing risk as well. This process is usually seen as traditional, old school, rigid, antithetical to the freedom and flexibility of the agile method.

All that’s true.

Hybridization

At the same time, there may be places where a gated handoff is beneficial in the sense that it keeps the loops smaller.  The holistic design process would lead to a frozen body of work that is passed through a waterfall-like gate to an engineering team using agile methods: a hybrid process.

The three-legged stool

Three parameters affect a project in general: scope, schedule and budget. Fixing more than one of these increases risk dramatically, yet by far the most common case is a project where budget and schedule are fixed, while scope remains bit fuzzy when work starts. Running on a fixed timeline with a fixed budget means a defined amount of person-hours is available; if scope increases, working hours in the schedule increase outside of budget, and margin falls. In an agile environment, scope changes are usually handled in the backlog prioritization, the assumption being that if scope increases sufficiently, some lower-priority tasks may not get completed. That’s a difficult concept to communicate to a client.

There’s no such thing as a free lunch

Everything in design, and in engineering, is a matter of compromise. The hybrid process described here assumes that UX design work reaches a predetermined complete state before the engineering process begins on that part of the design. This may mean that the design for the entire project should be completed first. It means that some design resources will need to be retained during the engineering phase, as changes will inevitably be required, to preserve the UX fidelity of the final product. It means the schedule for the project will probably be longer. In practice, however, the overall timeline usually suffers more from those large, unpredictable loops called out above. And in the end, correctly sizing a project, mitigating the risk and executing within project parameters are the factors that lead to success.