3 ways Scrum strengthened our UX team

How applying principles from Scrum unexpectedly led to solving problems we faced as a design team.

First of all, we do not follow a conventional Scrum process…

A typical Scrum team consists of the following members:

  • Product owner
  • Scrum master
  • Development team

(If you need more of a background on what Scrum involves, check out this article for an easy to read designer introduction.)

Our team instead consists of 4 UX designers with Scrum responsibilities split between us. No one takes on the role completely of product owner or scrum master, instead, we have assigned key responsibilities to each team member as a way to ensure the entire Scrum process could run while we continue delivering our UX work. In this way, we are working as one UX team that serves 3 development teams with design solutions.

The set up of our UX team as a “hub and spoke” model where we serve each scrum development team while applying principles from Scrum within our UX team.

At first, I was a bit hesitant to begin following some of the Scrum methodologies as just a UX team and not as members of the development teams. It’s not the traditional Scrum set up and I was worried it would make things too complicated when delivering our work. In fact, I Googled the heck out of it to find an example where anyone else had experience in a “UX Scrum team”. I was not able to find any examples, which only fueled my hesitancy even more. In the end, it was decided that this set up had the best potential to strengthen and unite us as a UX team so that we could improve our velocity and maintain better design consistency.

Fast forward 8 months later and we are now a stronger, more united team that works both individually to serve the development teams and together to unite our UX process and vision. We’ve found that scrumming together as a UX team has brought some of the missing structure that we were needing. So without further chatter, here are 3 ways that scrumming together has helped our team.

1. Aligning as a team around priorities and planning.

Before we started scrumming together, we were using a Kanban board set up in JIRA where we simply chose the work that was handed to us first and for our specific development team without the larger picture of what was needed across the teams. It meant that work could end up spanning weeks as we each individually worked on separate projects without the shared responsibility of breaking down and planning task completion.

After we started to Scrum as a team, we switched to a JIRA Scrum board where we started to break down our projects into smaller tasks that could be completed in a two week sprint. The idea of breaking down larger pieces of work into smaller chunks as part of the Scrum process helped our team feel as though we could move easier through larger projects and actually see progress towards a goal.

As we started to fill JIRA with tasks, we could more clearly see where the priority needed to land and could start sharing responsibilities on getting projects delivered in time for the development teams (aiming to be ready with the bulk of the work at least a sprint ahead of them). It also meant that we could more easily plan our own UX initiatives around the creation of design tools and process improvements while still delivering the needed work for the development teams.

2. Melting away egos and improving focus.

As designers, we can tend to attach emotion in the work that we complete. The more time we spend on a task, the more likely we become attached to the solution and the harder it is to accept critique. This was true before we started scrumming together.

By breaking down our work into smaller chunks that could be completed in a two week sprint, we could bring our whole team along on the design journey and share smaller iterations of solutions before we could get too involved or attached to our ideas. This helped us to slowly melt away egos that we had before we began scrumming together.

With less egos and a clearly defined “definition of done”, we found our focus improved during design critiques. By having a clear idea of the problem we wanted to solve, we understood how to critique designs according to whether they solved the problem and met the “definition of done”.

3. Working as a team, growing as a team.

Initially working as individuals, we would define the larger problem to be solved and then slowly move it through our Kanban board. We lacked a real sense of team on completing the work we delivered and we felt the pain when deadlines approached and work piled up.

When we began to break down work into smaller chunks that could be delivered in two week sprints, we found each other working together and motivating each other. This gave us a stronger sense of “team” and helped us feel a sense of accomplishment each sprint. As it was now possible that anyone could pick up a ticket, we felt more like a team trying to deliver a sprint and felt more aligned on the solutions we aimed to deliver.

By completing retrospectives each sprint, we were able to look back and learn from each other. Retrospectives ended up being the best opportunity to share with each other when we felt things weren’t going as well as planned and finding solutions together for improvement. We found this time of honest reflection helped us to open up and trust each other in a way that wasn’t possible 8 months earlier. It was through trusting each other that we began to also open ourselves up to learn from each other as well.

Final thoughts…

Working as a Scrum team of only UX designers may have been unconventional, but it has helped our team unite and grow together in ways we had not expected. Delivering larger projects is now something that we are able to better handle as a team, pushing each other to deliver even better experiences. The Scrum methodology ended up being the simple solution to the problems we were having as a team and it will be interesting to see how the next step of refining a more accurate UX portfolio plan in JIRA will have further impact on the team.