Mastering Agile UX — Part 2: Cross-team collaboration
Imagine taking a symphony orchestra like the one below and splitting it up into a number of separate mini orchestras. Each mini orchestra would have a distinct name, a distinct identify and way of working. Each would have their own conductor, vocalist, violinist, trumpeter, flutist, cello player and so on. Now put them in different concert halls, perhaps even different countries and ask them to collectively play a piece of classic music together. What do you think will happen? Will they miraculously play beautifully together, or will it sound more like a junior school’s first band practice? It’s certainly not a concert that I would pay good money to attend.
This sort of arrangement would be pretty strange for an orchestra, and yet it’s how most organisations set-up their Agile teams. It’s very common to have Agile teams working largely in isolation, perhaps in different locations and even different countries, even though they are working on the same product, or on similar products. Expecting these teams to create beautifully harmonious experiences for their users is like expecting our mini orchestras to be able to collectively conjure up Beethoven’s Fifth Symphony. Without a focused effort to push collaboration and co-ordination between teams, it simply isn’t going to happen.
In this second part of my mastering Agile UX series I’m going to cover some tips and advice for collaboration. Not for collaborating within an Agile team — that’s a very well-trodden topic and something that should happen very naturally. No, I’m going to focus on cross-team collaboration. In particular, collaborating with other UXers.
Incidentally if you’re wondering what the first part of mastering Agile UX covered if was managing your work within an Agile team. Although you don’t have to read the articles in order, I’d recommend checking out Mastering Agile UX — Part 1: Managing your work once you’ve read this article.
Ok, back to collaboration. Let’s start with where you sit, always a hot topic for any team.
Co-location, but with who?
Conventional wisdom dictates that a team that works together, should sit together. This is why the vast majority of Agile teams are co-located, or at least they used to be before Coronavirus left offices deserted. Conventional wisdom is not always the best sort of wisdom. Rather than sitting with your fellow Agile teammates (assuming that at some point in the future this will be possible), I’d urge you to instead sit yourself near to other UXers.
Let’s face it. You’ll be working with your Agile team day in day out, but this will no longer be the case with your fellow UXers. By sitting close by you can help to maintain close working relationships and encourage collaboration. If this means that you’ll be working on a different floor, or even different office to your Agile team then you might want to reconsider. However, in most modern open plan offices, you can sit near to other UXers and still be within earshot (and probably Nerf gunshot) of your Agile team.
Carving out time to collaborate outside of your team
Agile teams are set-up to encourage collaboration within the team, but often it seems they discourage collaboration outside of it. This is a shame because not only does collaborating with other teams, and fellow UXers result in better quality work, it can be very lonely if you’re the only UXer in an Agile team.
It’s important to consciously carve out time to work with those outside of your team. This could be something as simple as having regular catch-ups, pairing sessions, setting time aside for group workshops or even having a regular day when you will work with others outside of your team.
If your workload is currently light it can be a good idea to ask other teams if there is anything you can help out with. You certainly should be able to take on work outside of your team, just so long as it doesn’t become too much of a distraction.
Collaborating on the holistic user experience
One area in particular that cross-team collaboration should focus on is the holistic user-experience for a product or service. It’s all too easy for an Agile team to only consider their own work in isolation. It’s important to regularly step back and look at the bigger picture from a user’s perspective. Activities such as cross-team planning, experience mapping and user story mapping can help to do this, and are great candidates for cross-team collaboration.
Sharing insights outside of your team
Does this sound familiar to you? Two different Agile teams are working on the same, or similar products. Each is speaking to their customers (brilliant), possibly even the same customers. Each is learning a lot about their customers, but like precious treasure, these valuable insights are kept under lock and key within the confides of their team.
Sharing insights outside of your team is critical for cross-team collaboration. A great way to do this is by establishing knowledge sharing mechanisms with other teams. For example, if there is another Agile team working on the same product, or a similar one then you could set-up regular insights sharing sessions with this team. A research repository, also known as an insights repository, is also a great way to ensure that insights are not only retained within the team, but are available and utilised outside of it as well.
Take a look at my guide to building an insights repository, along with Jonathon Richardson’s I built a user research repository — you should do the same article for more about why an insights repository is so useful, and how to go about building one.
Using insights from outside of your team
An Agile team can soon become an echo chamber — a place where knowledge and views are shared and reinforced within a closed system. It’s important to break free of this ‘group think’, by not only sharing insights outside of your team, but importantly also utilising insights from other teams. Remember that sharing insights should be 2-way traffic, not a 1-way system.
Finding the best UX model
Having UXers working within Agile teams can be brilliant, but it’s not the right model for every team, for every project, or indeed for every organisation. Working within an Agile team can have many benefits, but it can also come with many downsides. As Peter Merholz and Kristin Skinner describe in their excellent Design Org for Design Orgs book:
“While decentralized (a.k.a. embedded) models work better (than centralised) in the near term, over time the following kinds of issues arise:
- Teams are focused on one problem for a long time
- Designers become lonely and disconnected
- There is little cohesive design culture and community
- The user experience is fractured
- There are inefficiencies as efforts are duplicated
- User research is marginalized.”
The truth is that Agile is optimised for development, not for UX. It’s about speed over quality. Agile is a great way to release code quickly, but it’s not necessarily a great way to deliver a high-quality experience for your users.
If a high-quality user experience is essential to be successful, then shackling UXers within Agile teams and restricting their capacity to collaborate outside of those teams might not be the best way to achieve it.
Many organisations are starting to explore alternative models including a hybrid approach (see diagram below). This is halfway between a centralised UX team and fully embedded model. The idea is that by having groups of UXers supporting a small number of Agile teams, they will collaboration with those teams, but also with their fellow UXers. This is a model that Peter Merholz and Kristin Skinner champion in their design org book and one that I’d recommend you to at least consider.
Conclusion
“Any organisation that designs a system … will produce a design whose structure is a copy of the organisation’s communication structure.” Conway’s law
Conway’s law tells us that Agile teams working in isolation, with little cross-team collaboration will all too often design products and services that are fragmented, disjointed, riddled with design debt, and that ultimately delivery a poor experience for their users.
Whilst engineers can hide behind their APIs, cross-team collaboration is a key component of Agile UX. By forming communication structures outside of your Agile team, and regularly utilising them you can help to break down the walls that can build up between Agile teams and can hopefully deliver a better experience for your users.
If you like this article then please recommend and share it. You can find lots more articles like this on my blog: UX for the Masses
See also
Images
Originally published at http://www.uxforthemasses.com on November 3, 2020.
