In the first part of this series, we discussed the challenges of integrating UX activities into an Agile context mainly populated by engineers (or, to use Scrum's terminology, developers). In this second part, we'll discuss various approaches to accommodating UX activity inside a Scrum framework.
While many have noted the importance of creating synergy among business analysts, UX designers, and developers in ensuring successful product development in an Agile context, the Scrum framework fits better with development processes than UX design processes and does not specifically prescribe a methodology for uniting the two. Thus, the way that Scrum teams deal with their business requirements as related to UX activity reflects their level of expertise, or maturity, in adopting an Agile environment. When companies with a background in Waterfall begin to transition to Agile, or even when software consulting firms work in short-term partnerships with design agencies, there can be significant gaps that lead to undesirable Waterfall processes.
Common Issues
The lowest organizational maturity level in adopting Agile may be illustrated in a scenario where a design department or design agency plans their entire solution up front before handing their project to a software department or consulting firm. The development work may have been completed according to Scrum recommendations, but the practice is definitely not Agile if the development team is not involved from the beginning. In this scenario, it's common that product owners won't even analyze the value of each feature in order to compose a proper backlog based on business requirements. The late involvement of software engineers causes solution mismatches, which in turn cause delays in product releases as well as investment losses--the very problems Agile was created to address.
The Dual-Track Scrum Solution
To address this issue, we move to a more mature adoption of Agile practices as proposed by Agile evangelist Jeff Patton. His approach, depicted below, tries to reduce the gap between design and development by breaking the process of product conception (or, as he calls it, product "discovery") into sprints. In this approach, each discovery sprint is immediately followed by a development sprint. If well enacted, this "Dual-Track Scrum" system can greatly reduce the time gap between ideation and software increment development. On the other hand, the system relies heavily on Agile maturity and communication best practices between discovery and development teams since the two teams are working on different parts of the same software increment and can easily revert to a Waterfall mindset if they don't regard their work as wholly united.
Atlassian representation of Patton's Dual-Track Scrum approach
Google's Design Sprint Kit Solution
In an even more mature adoption of Agile practices, an organization might use Google's 3 or 5-day design sprint strategy, depicted below, to gather information for starting a development sprint. In this model, the output of a design sprint can be refined during the development sprint with sufficient participation from both UX and software engineers. A 3-day sprint design can be conducted by anyone in the team with communication and information-gathering skills, and it may be performed in parallel with the current development sprint. Successful design sprints inform subsequent sprint planning sessions, or any other sprint that suits the product best, and ideas that fail the sprint design test may be discarded without regret since only a couple days have been allocated for exploration rather than months or even an entire year. With these adjustments and tools, UX and development professionals can work so well as a single team that the limits of each are barely distinguishable.
Google design Sprint Phases & Methods Diagram
Further Developments
As this paradigm became a common practice in development, it was applied in other diverse contexts as well. For instance, Brad Frost popularized "atomic design," which uses chemistry vocabulary to demonstrate how to slice UI components into their most granular levels in order to make each level reusable. The atomic design approach attempts to frame design systems with a logical creation process. This model envisions design systems as enormous, living policies containing design guidelines that shape the brand's web appearance, prevent the need to rework UI elements, and standardize common interaction patterns through the interface, making both design and UI development jobs easier.
Design systems have recently been taken to a further level of development with the Airbnb React Sketch App. The Airbnb library allows developers to access a collection of components, customize them with React, and render every input instantly in the prototype tool Sketch. This empowers UI developers to easily find, try, and suggest commonly used components, allowing UX professionals to research, create, and reshape improved interactions instead of starting component design and development from scratch every time a basic feature has to be reused in a different context.
Example of Airbnb React Sketch App
The Airbnb approach integrates the design system and code repository. This combination prevents time consuming issues, such as tune responsiveness in different devices, transition effects, alignment, and font issues in each component reuse. Impressive developments like the React Sketch app can introduce a new mindset to the relationship between UX and development teams, revolutionizing their interactions for increased speed and capability in product development.
While there are still solutions to be explored to help UX and development team interactions gain efficiency, this article provides explanations and tools that can help your Agile practices mature. At Avenue Code, we're well-versed in implementing Agile to increase internal corroboration, productivity, and overall business operation success.
