Are you getting the most from your Agile and UX approaches?
If you've ever been in a team building a product - especially if it involves some digital aspect - you surely have come across the age old topic of balancing the tension between design and development, which often materialises itself today as a convergence or conflict between Agile and UX.
There is much material out there on how to combine Agile and UX, but often these guides aren’t very deep and don’t illuminate why that particular combination is better than others. Thus it's often easy to choose an approach which can lead to poor outcomes - even if the intentions were good.
Here's some points to consider to choose a combined Agile and UX approach to avoid that scenario in your product team.
There is much material out there on how to combine Agile and UX, but often these guides aren’t very deep and don’t illuminate why that particular combination is better than others. Thus it's often easy to choose an approach which can lead to poor outcomes - even if the intentions were good.
Here's some points to consider to choose a combined Agile and UX approach to avoid that scenario in your product team.
Competing perspectives
Agile can often focus more on development practices, due to the emphasis on 'delivering working software frequently' (especially teams with a heavy technical background or new to the digital or Agile world). ‘Technical excellence’ practices such as CI, CD, test automation etc. are now commonplace (and rightly so), but Agile teams shouldn't let that focus overlook design aspects which shouldn’t just be the sole responsibility of the Product Owner or a UX designer.
In addition, code (if well written and maintained) is relatively easy to change - much easier than adjusting user perceptions of a product, post-launch. But sometimes this results in an overly emergent approach to developing products that neglects the need for well executed UX activities.
On the other hand, UX designers can often overlook the complexity involved in 'building' a product at a high level of quality – and that’s even before teams start to consider constraints such as cost and scope. No matter how well synthesized user research is nor how deep the UX insights are - it is the convergence of development and the design where brilliant ideas run into the practicalities of reality.
Agile can often focus more on development practices, due to the emphasis on 'delivering working software frequently' (especially teams with a heavy technical background or new to the digital or Agile world). ‘Technical excellence’ practices such as CI, CD, test automation etc. are now commonplace (and rightly so), but Agile teams shouldn't let that focus overlook design aspects which shouldn’t just be the sole responsibility of the Product Owner or a UX designer.
In addition, code (if well written and maintained) is relatively easy to change - much easier than adjusting user perceptions of a product, post-launch. But sometimes this results in an overly emergent approach to developing products that neglects the need for well executed UX activities.
On the other hand, UX designers can often overlook the complexity involved in 'building' a product at a high level of quality – and that’s even before teams start to consider constraints such as cost and scope. No matter how well synthesized user research is nor how deep the UX insights are - it is the convergence of development and the design where brilliant ideas run into the practicalities of reality.
Despite these seemingly conflicting perspectives, there is one thing that both Agile and UX practitioners can agree on - no one in their right mind would want to ship a terrible product.
Context matters
It is possible to deliver amazing products in today’s often hyper-connected, capital focused market, the but the major challenge is managing the scarce resource of time. Trade-offs need to be made to balance competing priorities (such as but not only: deadlines versus depth of research, new features versus overall accessibility), and from our experience, there is no one ‘perfect approach’ for every situation.
Thankfully, the one thing that both Agile and UX approaches advocate is the importance of working in iterations - you can adjust your area of focus over the lifetime of a product, given various changes in context.
That context is shaped by factors including the type of product, purpose, scale and risk. For instance, UX activities required for updates to an existing feature will not be as deep as those required to take a non-existent product to market for the first time.
Another consideration is problem clarity. If you are still not sure of the right problem to solve then you may need to increase the scope or depth of your UX research activities; but you may be more likely to move to delivery activities if you already knew the problem/opportunity and needed to find the best way to solve or exploit the situation.
Side note: We find that the Cynefin body of work on complexity to be fantastic with assisting with decision making (explaining the basics of this may need a separate post!).
It is possible to deliver amazing products in today’s often hyper-connected, capital focused market, the but the major challenge is managing the scarce resource of time. Trade-offs need to be made to balance competing priorities (such as but not only: deadlines versus depth of research, new features versus overall accessibility), and from our experience, there is no one ‘perfect approach’ for every situation.
Thankfully, the one thing that both Agile and UX approaches advocate is the importance of working in iterations - you can adjust your area of focus over the lifetime of a product, given various changes in context.
That context is shaped by factors including the type of product, purpose, scale and risk. For instance, UX activities required for updates to an existing feature will not be as deep as those required to take a non-existent product to market for the first time.
Another consideration is problem clarity. If you are still not sure of the right problem to solve then you may need to increase the scope or depth of your UX research activities; but you may be more likely to move to delivery activities if you already knew the problem/opportunity and needed to find the best way to solve or exploit the situation.
Side note: We find that the Cynefin body of work on complexity to be fantastic with assisting with decision making (explaining the basics of this may need a separate post!).
From Cognitive Edge
With that understanding of mindset and context, we then see some common patterns to blend Agile and UX together, each with their own strengths and weaknesses.
Combining Agile and UX
(Note: the diagrams are heavily simplified for illustrative purposes only, splitting UX work into “pre-production” and “production” type activities, calling out a generic “development” activity for all other work required to build a product, and mapped to arbitrary sprints. Apologies to anyone that feels left out by this simplification, I promise it wasn’t on purpose.)
(Note: the diagrams are heavily simplified for illustrative purposes only, splitting UX work into “pre-production” and “production” type activities, calling out a generic “development” activity for all other work required to build a product, and mapped to arbitrary sprints. Apologies to anyone that feels left out by this simplification, I promise it wasn’t on purpose.)
1. UX 'pre-production' work (research, architecture and design) is completed ahead of 'development'.
This is the most common approach referred to today; one we often see with large companies who split development and design activities for ease of management (or more often, to facilitate a seemingly better deal from suppliers).
This is the most common approach referred to today; one we often see with large companies who split development and design activities for ease of management (or more often, to facilitate a seemingly better deal from suppliers).
Whilst this allows UX work to be 'ready' ahead of the development activities, this delay between design and development also encourages problems to arise from back-and-forth communication between siloed activities (often referred to as an anti-pattern in Agile environments).
This usually means that either:
This may suit where heavy amounts of design before any development starts, but not many companies, start-ups or Agile have the luxury of time or money to wait too long on this.
This usually means that either:
- UX work goes into to a level of depth which does not contribute meaningful information for development activities (e.g contextual interviews too wide, researching all possible personas instead of focusing on those which will return value soonest) or
- Either design or development is done without enough insight and feedback from the other, until it’s too late.
This may suit where heavy amounts of design before any development starts, but not many companies, start-ups or Agile have the luxury of time or money to wait too long on this.
2. UX is done within the sprint.
This is most 'Agile' approach which can result in the holy grail of frequent delivery of features (across the entire stack), often multiple times a sprint.
This is most 'Agile' approach which can result in the holy grail of frequent delivery of features (across the entire stack), often multiple times a sprint.
However, this can be stressful depending on what is required to deliver a meaningful product for users within the sprint (not just 'working software’ as per the Agile manifesto). This is especially true if the team are not used to the concept of emergent design or do not have a clear direction/roadmap. Prioritisation can also be tricky as it involves making trade-off between complexity and effort, as well as what to keep and what to defer.
In our experience, a high level of transparency across the teams (and also the organisation) will support this type of approach, especially due to the need for rapid decision making.
3. "Design Sprint" and similar methods
Collaborative approaches to validate assumptions before developing the product (such as those similar to Google Venture's wildly popular Design Sprint) are another way of blending Agile, Design and UX, requiring the whole team to pair on user engagement and wireframing/prototyping (at a low fidelity).
Delivery can then happen through a feature or component based model – Agile often advocates the former, especially in teams equipped with full-stack developers.
Collaborative approaches to validate assumptions before developing the product (such as those similar to Google Venture's wildly popular Design Sprint) are another way of blending Agile, Design and UX, requiring the whole team to pair on user engagement and wireframing/prototyping (at a low fidelity).
Delivery can then happen through a feature or component based model – Agile often advocates the former, especially in teams equipped with full-stack developers.
Often in this model you will see the 'diverge/converge' model in various shapes and forms, and often helps where the most ideal solution hasn't been discovered yet, or the problem statement still needs to be refined; but where there is also a firm need to deliver something sooner rather than later.
To avoid any unnecessary rework, teams need to maintain open channels of communication so that any change (no matter how small) is understood.
To avoid any unnecessary rework, teams need to maintain open channels of communication so that any change (no matter how small) is understood.
4. Hybrid methods
Hybrid methods also exist where UX practitioners are part of the Agile team, but also have regular occurrences of longer research or ideation activities happening in parallel to the delivery process (sometimes limited to a short time box).
Hybrid methods also exist where UX practitioners are part of the Agile team, but also have regular occurrences of longer research or ideation activities happening in parallel to the delivery process (sometimes limited to a short time box).
This may only take place every few sprints, taking into account time required to gather feedback, as well as organisation of activities such as usability testing. This approach helps to ensure that the blueprints are kept current, whilst still being able to deliver features frequently.
Plan, learn from experience, and keep trying
These examples show that there is plenty of flexibility when it comes to incorporating Agile, Design and UX approaches in the creation of meaningful products. Finding the right approach requires consideration of context, collaboration to find the right balance, and even more “doing” in order to learn from concrete experience. In fact, this could also be applied to other practices or disciplines not mentioned in this article.
This may require some tough conversations, compromises and some deep listening in order to understand the different perspectives, but this will help to avoid the outcomes that all Agile, Design and UX practitioners shun: a poor product with minimal impact on the market, delivered by a team that feels like it is spinning around in circles- or even worse, grinding to a halt.
- Daryl (with thanks to Ada Yuen, Jelena Uljankina and Pedro Pimentel)
RSS Feed