Loading...
article details
READ TIME 5 MINS
Date published 2019
Publisher UX COLLECTIVE
WRITTEN BY ARIELLE COOK
How to allow for UX magic in an agile world.

Having worked as an Experience Designer in-house, and for both creative agencies and consultancies, I’ve been exposed to the different ways in which Agile can be adopted within organisations, along with the common factors that help UX and Agile/Scrum not only co-exist, but thrive as well.

Agile has fundamentally changed the way we work. Not only in terms of the way we develop software, but increasingly how we organise and structure entire organisations. In Australia, the appetite and demand for Enterprise Agility has generated interest on a global scale, with ANZ publicly declaring themselves an Agile organisation and rolling out Scaled Agile to 13,000 employees across their run and change business units.

Growth of Agile is strongly correlated to the rapid rise of digital technology, which has evolved customer needs and expectations while destabilising markets and fuelling competition. Large and established industries have been disrupted by smaller, more nimble customer-centric startups focusing on developing the more profitable segments in their value chain. These disruptors have forced larger, established organisations to rethink their operating models to become more flexible and adaptive in order to react quickly and frequently to meet the ever evolving needs of their digital customers.

Agile is at the core of this new operating model, due to its ability to react quickly and deliver frequent and continuous value to customers through a number of factors such as, heightened team and stakeholder engagement, early and predictable delivery, ability to change course or direction in a project, and increased collaboration and quality, to name a few.

However despite its successes, I often feel that it could be more accomodating for UX designers. The reality is that Agile was designed with a sole focus on developers (as seen in the detailed Agile Manifesto), meaning UX was never considered and fundamental processes required to create great user-centric designs, such as research and usability testing, are non-existent within the Agile paradigm. There are 2 main consistent pressures I have found when observing organisations trying to shoehorn UX into a traditional Agile/Scrum structured team;

  • Sprint timings

    One of the main focuses of Scrum is the sprint timing structure. Having a team work towards task completion within a 1 or 2-week sprint cycle does not always fare well for us UX designers. Applying a short sprint timing structure from the beginning of a project puts UX designers under an enormous pressure to create, test, refine, and deliver their outputs unrealistically fast.

  • Unified sprint Goals

    The Agile paradigm focuses on the entire team working on the same features and objectives simultaneously throughout a (commonly) 2 week sprint (cycle). Having this sprint goal focus in a team poses two main concerns;

    1. As UX designers, we are to pave the road forwards for our team, with our research, wireframes, testing and designs. Having to complete these tasks ahead of development means that UX designers will often have different goals to that of the rest of the team, which typically causes issues in grooming and planning stages; given teams like to focus on their immediate tasks rather than what lies ahead.
    2. As UX designers we consistently strive to create seamless and holistic experiences. Having a team focus on a singular sprint goal, makes it easy to miss potential large-scale design implications, such as integration or omni-channel consistency within a project.

However all is not lost! There are many UX designers that have not only flourished in Agile/Scrum environments, but strongly advocate for it too. Successful Agile/Scrum environments are characterised by key factors that help overcome some of the obstacles mentioned above, and in turn, allow UX and Agile to not only co-exist but thrive as well;

  • Sprint Zero

    The Agile/Scrum process does not favour much in the way of upfront research or discovery, preferring learning through continuous deployment experimentation. UX designers, in contrast, have a preference for research to commence at the beginning of a project in order to build basic assumptions and hypotheses that inform product strategy and ongoing decision-making within a project. Upfront UX research is typically contingent on the UX maturity within the organisation. If people within the organisation are understanding of the UX process (and back it), managers are likely to implement a ‘sprint zero’ at the beginning of a project, this allows UX designers to be brought on before the engineering team to complete the initial discovery and research phases.

  • Tight-knit teams

    Research, design, product strategy, and software architecture should be understood by the whole team. While each of these disciplines have specific roles to play, every aspect of the product-development process benefits from the balanced participation of a multidisciplinary product team. These tight-knit teams consistently challenge the design and development of a project and then integrate the feedback into the coming sprints, successfully resulting in a more human-centred product. Over the years I have found that these tight-knit teams thrive in Agile environments once they reach a stage of product maturity, where both the UX and development teams are equally knowledgeable on their users, architecture restrictions, and product vision. Having this team relationship and maturity also enables greater collaboration when designing new solutions or product features.

  • Flexible Agile implementation

    Agile was originally developed (before the message got lost along the way by its passionate evangelists) to deal with with changes in product requirements in a more economical, sustainable and Agile way. UX and Agile can co-exist well when the rules and processes are allowed to adapt for differing workplace environments. If an organisation has Scrum Master sticklers that use countdown timers in stand-ups, and wont allow UX to work on designs a sprint or two ahead of the developers, it becomes very tough for UX people to be more than pixel-pushers.

As Jake Causby from SiteMinder puts it: “There’s no such thing as ‘best practice’; only better practice”


In summary, UX in an Agile/Scrum team is about collaboration, leadership, and flexibility. Success in these environments is characterised by:

  • UX maturity within the organisation and allowing for a Sprint Zero

  • Progressive and proactive tight-knit teams that are equally knowledgable on their users and allow for design collaboration

  • A workplace that is flexible in their Agile implementation that allows for UX practitioners to work at least 1–2 sprints ahead if need be.

The more that the UX and Agile product teams succeed in finding common ground in addressing typical issues like the ones outlined above, the more time we will have to refine, collaborate and improve our product design and user experience.

article details
READ TIME 5 MINS
Date published 2019
Publisher UX COLLECTIVE
WRITTEN BY ARIELLE COOK
How to allow for UX magic in an agile world.

Having worked as an Experience Designer in-house, and for both creative agencies and consultancies, I’ve been exposed to the different ways in which Agile can be adopted within organisations, along with the common factors that help UX and Agile/Scrum not only co-exist, but thrive as well.

Agile has fundamentally changed the way we work. Not only in terms of the way we develop software, but increasingly how we organise and structure entire organisations. In Australia, the appetite and demand for Enterprise Agility has generated interest on a global scale, with ANZ publicly declaring themselves an Agile organisation and rolling out Scaled Agile to 13,000 employees across their run and change business units.

Growth of Agile is strongly correlated to the rapid rise of digital technology, which has evolved customer needs and expectations while destabilising markets and fuelling competition. Large and established industries have been disrupted by smaller, more nimble customer-centric startups focusing on developing the more profitable segments in their value chain. These disruptors have forced larger, established organisations to rethink their operating models to become more flexible and adaptive in order to react quickly and frequently to meet the ever evolving needs of their digital customers.

Agile is at the core of this new operating model, due to its ability to react quickly and deliver frequent and continuous value to customers through a number of factors such as, heightened team and stakeholder engagement, early and predictable delivery, ability to change course or direction in a project, and increased collaboration and quality, to name a few.

However despite its successes, I often feel that it could be more accomodating for UX designers. The reality is that Agile was designed with a sole focus on developers (as seen in the detailed Agile Manifesto), meaning UX was never considered and fundamental processes required to create great user-centric designs, such as research and usability testing, are non-existent within the Agile paradigm. There are 2 main consistent pressures I have found when observing organisations trying to shoehorn UX into a traditional Agile/Scrum structured team;

  • Sprint timings

    One of the main focuses of Scrum is the sprint timing structure. Having a team work towards task completion within a 1 or 2-week sprint cycle does not always fare well for us UX designers. Applying a short sprint timing structure from the beginning of a project puts UX designers under an enormous pressure to create, test, refine, and deliver their outputs unrealistically fast.

  • Unified sprint Goals

    The Agile paradigm focuses on the entire team working on the same features and objectives simultaneously throughout a (commonly) 2 week sprint (cycle). Having this sprint goal focus in a team poses two main concerns;

    1. As UX designers, we are to pave the road forwards for our team, with our research, wireframes, testing and designs. Having to complete these tasks ahead of development means that UX designers will often have different goals to that of the rest of the team, which typically causes issues in grooming and planning stages; given teams like to focus on their immediate tasks rather than what lies ahead.
    2. As UX designers we consistently strive to create seamless and holistic experiences. Having a team focus on a singular sprint goal, makes it easy to miss potential large-scale design implications, such as integration or omni-channel consistency within a project.

However all is not lost! There are many UX designers that have not only flourished in Agile/Scrum environments, but strongly advocate for it too. Successful Agile/Scrum environments are characterised by key factors that help overcome some of the obstacles mentioned above, and in turn, allow UX and Agile to not only co-exist but thrive as well;

  • Sprint Zero

    The Agile/Scrum process does not favour much in the way of upfront research or discovery, preferring learning through continuous deployment experimentation. UX designers, in contrast, have a preference for research to commence at the beginning of a project in order to build basic assumptions and hypotheses that inform product strategy and ongoing decision-making within a project. Upfront UX research is typically contingent on the UX maturity within the organisation. If people within the organisation are understanding of the UX process (and back it), managers are likely to implement a ‘sprint zero’ at the beginning of a project, this allows UX designers to be brought on before the engineering team to complete the initial discovery and research phases.

  • Tight-knit teams

    Research, design, product strategy, and software architecture should be understood by the whole team. While each of these disciplines have specific roles to play, every aspect of the product-development process benefits from the balanced participation of a multidisciplinary product team. These tight-knit teams consistently challenge the design and development of a project and then integrate the feedback into the coming sprints, successfully resulting in a more human-centred product. Over the years I have found that these tight-knit teams thrive in Agile environments once they reach a stage of product maturity, where both the UX and development teams are equally knowledgeable on their users, architecture restrictions, and product vision. Having this team relationship and maturity also enables greater collaboration when designing new solutions or product features.

  • Flexible Agile implementation

    Agile was originally developed (before the message got lost along the way by its passionate evangelists) to deal with with changes in product requirements in a more economical, sustainable and Agile way. UX and Agile can co-exist well when the rules and processes are allowed to adapt for differing workplace environments. If an organisation has Scrum Master sticklers that use countdown timers in stand-ups, and wont allow UX to work on designs a sprint or two ahead of the developers, it becomes very tough for UX people to be more than pixel-pushers.

As Jake Causby from SiteMinder puts it: “There’s no such thing as ‘best practice’; only better practice”


In summary, UX in an Agile/Scrum team is about collaboration, leadership, and flexibility. Success in these environments is characterised by:

  • UX maturity within the organisation and allowing for a Sprint Zero

  • Progressive and proactive tight-knit teams that are equally knowledgable on their users and allow for design collaboration

  • A workplace that is flexible in their Agile implementation that allows for UX practitioners to work at least 1–2 sprints ahead if need be.

The more that the UX and Agile product teams succeed in finding common ground in addressing typical issues like the ones outlined above, the more time we will have to refine, collaborate and improve our product design and user experience.