why innovation!
  • Services
  • Training
  • Who We Are
  • Reach Out
  • Join Why Team
  • Buzz
    • Y Community

Agile and UX - you can do better

7/21/2017

1 Comment

 

Are you getting the most from your Agile and UX approaches?

Picture
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.
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.​
Picture
​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!).
Picture
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.)
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).
Picture
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:
  • 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.

Picture

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.
Picture
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. 
​
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).
Picture
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)
1 Comment
Pedro Pimentel link
7/31/2017 01:20:14 am

Outstanding article. I specially liked the handcrafted watercolour illustrations!

Reply



Leave a Reply.

    Archives

    October 2019
    September 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    June 2018
    May 2018
    February 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017
    April 2017
    March 2017
    February 2017
    January 2017
    November 2016
    October 2016
    September 2016
    August 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    January 2016
    November 2015
    October 2015
    February 2015
    January 2015
    October 2014
    September 2014
    August 2014
    July 2014

    Categories

    All
    2017
    2018
    2019
    Ability
    Adatability
    Adoption
    Agile
    Agile Beer
    Agile Leadership
    Agile Transformation
    Asia
    Asian
    Australia
    Blog
    Business Modeling
    Business Model Innovation
    Buzz
    Challenge
    Change Management
    China
    CIO
    Coaching
    Community
    Compatibility
    Conference
    Congress
    Culture
    Cybersecurity
    Delivery
    Design Thinking
    Developers
    Digital Transformation
    Education
    Enterprise
    Entrepreneur
    Event
    Experts
    Flexibility
    Gala
    HongKong
    Hong Kong
    Human Resources
    Implementation
    Innovation
    InsurTech
    International
    Interview
    IT Consulting
    IT Leadership
    January
    Leading SAFe 4.0
    Lean Agile
    Lean-Agile
    Lean Startup
    Learning
    Lego
    Malaysia
    Management
    Manifesto
    Meetup
    One-size-fits-all
    Organizational Change
    PMI
    Press Release
    Product Owner
    Product-Owner
    Professional
    PSD
    PSM
    PSPO
    Red Dot Innovation
    Red Dot Innovation!
    Red-Dot Innovation!
    Risk
    SAFe
    Scaledagile
    Scrum
    Scrum Master
    Scrum-Master
    September
    Service Design HK
    Singapore
    Software
    Storytelling
    Success
    Teaching
    Totem Dance
    Trainer
    Training
    Transformation
    USA
    UX
    Values
    Vietnam
    #WeAreWhyers
    Western
    Why Innovation!
    Workshop
    YOW

    RSS Feed

Singapore

​#08-06/07 ARC 380
380 Jalan Besar
​Singapore 209000

Hong Kong

Unit D, 11/F, Splendid Centre
94-108 Larch Street,
​Tai Kok Tsui, Kowloon

ShangHai

#1107,1602 Zhong Shan Road (W)
​Shanghai 200235
CONTACT US
  • Services
  • Training
  • Who We Are
  • Reach Out
  • Join Why Team
  • Buzz
    • Y Community