Part 2 Modifying Scrum to Marry UCD and Agile – Modification 2: Half-phase offset

Our last post outlined the similarities between user-centered design best practices and agile development best practices; introduced how TandemSeven makes four ‘modifications’ to a typical scrum process to arrive at a modified scrum; and described Modification 1: Minimal upfront user interface design.

This post discusses Modification 2: Half-phase offset. Let’s start off by comparing another set of best practices between the two processes:

User-centered design best practice: Think through a broad but shallow full design picture, and drill down into more detail as needed. With the ‘big picture’ in mind, designers can recognize opportunities for consistency, without having to spend too much time in one particular area.

Agile development best practice: Identify user stories and build only what is required within the current sprint. As more user stories are added, inconsistencies will occur. Create additional user stories to remove the inconsistencies from what has already been built.

In reality, the agile best practice mentioned above is severely hampered by priorities and other factors, such as project deadlines and timelines. If a change is identified but isn’t prioritized high enough, it usually will not be completed. This can lead to a residue of inconsistencies resulting from changes that are not prioritized high enough to fix.

Modification 2: Half-phase offset

UI work occurs in iterations; development work occurs in sprints. UI work is one-half phase ahead of development, allowing for a truly agile UCD process. (Many practitioners in the user-centered design community advocate a full phase offset, but our experience shows full phase offsets often evolve into mini waterfalls.)

Why this compromise?
Utilizing a half-phase offset between UI designers and developers helps solve this problem. As part of iteration zero, designers begin work on what is to be built in the first sprint, then continue to stay one-half phase ahead of the developers in subsequent sprints. This allows the UI designers to have a better understanding of the design and the consistencies desired before the developers become involved. Once the developers are ready and collaboration begins, the capabilities and input of the developers will help guide refinements to the design. The UI designers continue to be engaged in that activity and can make any necessary changes as problems arise, but move onto the next task once the development is at the halfway point.

The half-phase offset encourages rapid collaboration and input between designers and developers than a full phase or several phase offset. The half-phase offset allows designers time to think things through before the developers begin work, but still allows time to make necessary changes while the developers are engaged.

A Web site’s forgotten password function needs to be redesigned to increase security. The design team must introduce several additional security and validation questions to the process. Using a half-phase offset, the UI designers begin their design cycle in the middle of the prior development cycle. The UI designers cultivate ideas, analyze them, then pick the best ones. When the developers become involved, the ideas are further explored for feasibility. Some may be discarded if, for example, a design idea cannot meet the developer’s security standards. Developers at this point may also suggest an alternative, such as utilizing an existing model they have built somewhere else on the site. Next, the UI designers document the changes and work alongside the developers until development is halfway complete before moving on to the next phase.

In conclusion, a half-phase offset maintains consistent collaboration between UI designers and developers, helping minimize inconsistencies. Watch for “Modification 3: Just Enough Documentation” in my next blog.

Related Posts