Pragmatic Agile UX: Harmonizing Unrelated Functional Teams to Ensure Great UX Design

Agile UX is great in theory, but does it always work?

It does work smoothly when all functional teams - business, technology, UX - are part of the same organization. This is because there is a common, governing frame of reference about goals, timelines and also for resolving trade-offs and conflicts. 

However, for projects involving multiple teams belonging to different organizations, making agile UX work is usually a nightmare. Each team has it's own implicit agenda, time-pressures, protocol and generally, a sheer lack of motivation to see the other team's perspective or solve problems jointly. As a result, despite having a capable project leader, quality of user experience design work often suffers.

This talk encourages project owners to acknowledge this inherent problem and take concrete steps to fix it pragmatically.

The innovative, modified agile UX methodology to be shared has been created on extensive first-had experience of agile environments and inherent pitfalls in doing UX work when disparate teams are involved. Apart from traditional usability engineering and project management best practices, this innovative agile UX method draws from emerging research in persuasion psychology and meta-usabilty. 


4 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

The talk will unfold through 3 insightful case studies of projects the speaker has personally led for prominent local and international clients. The audience will learn about Modified Agile UX Methodology and apply it to their own projects. The 3 case studies chosen will be for a good mix of diverse platforms (Intranet, Mobile App and Web-based Enterprise Application).


Learning Outcome

- Understand the strategic issues involved in managing UX in agile environments with disparate functional teams

- Know how to modify the existing project methodology to address the issues affecting UX design

- Understand the resources and protocol needed to implement the new, modified agile UX methodology  

Target Audience

project managers and business leaders

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Naresh Jain
    Naresh Jain
    schedule 1 year ago
    Sold Out!
    45 Mins

    On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

    It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

    In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

  • Liked Adam Burke

    Adam Burke - Building Memory Palaces From Ontological Slime

    45 Mins

    Software systems are complex, both in the everyday sense, and in the more technical sense used by complexity science. This suggests reasons why agile software development and design are effective, including the usefulness of human feedback and of reducing localised complexity in code. We also have an agile idea, from Peter Naur, that a large part of programming is building and improving a model of the system in the programmer’s head. What does that imply about the world, or at least, the worldview of an effective programmer? This talk argues that software is a complex system and introduces William Wimsatt’s ideas of “causal thickets” and “ontological slime” as tools of navigation and classification for the working software developer.