A few quick notes
• At the time, my scrum team consisted of 1 UX designer (me), 1 UI designer, 1 PM, 1 business analyst, 1 scrum master, 2 front-end developers, and 6 backend developers.
• I capitalize a few words to refer to the cohorts within the team: Design = me and my UI designer, Product = my PO and PM, and Development = all of the developers.
• Illustration credit: Pablo Stanley, Open Peeps Illustration Library
My scrum team at SunTrust was tasked with carrying out a two-part initiative: 1) design and build the internal tool that would be used to onboard and manage clients on our new SSO platform and 2) design and build the client onboarding experience for the platform. The bulk of the delivery work began in January 2019.
After a couple of sprints, it became clear that we did not have a solid process for planning and delivering work and that it was hamstringing us. To make matters worse, Dev leadership and Product leadership were facing pressures that they weren’t openly sharing with the full group which led to in-fighting and tension within our team.
Why was solving this problem important?
This was a large, highly-visible project, and we had a lot of work ahead of us. Things had gotten to a point where I felt that I was always on the defense, frustrated, unappreciated, and unheard, and I was sure the others felt similarly. This was not how I wanted the project to continue.
One major issue that complicated matters was Product, Development, and Design were all hearing conflicting messages from our respective leaders. Getting leadership to align ended up being a separate effort later on, but, in the meantime, we had to acknowledge the conflicting goals and motivations within our scrum team and try to find some common ground. Through multiple 1:1 and team conversations, I learned:
My PM was given a huge list of features to deliver and a short timeline. He also knew that it would be crucial to keep our various client services groups heavily involved to ensure that the solution was something that they could actually use (translation: lots of cross-functional meetings and scope calls). Because we had not established a team process, he assumed that if he didn't see designs every day that design work was not being done. This resulted in unfocused sprint and release planning, as well as a lot of unnecessary escalations and finger-pointing.
The developers had grown accustomed to working in an environment where their work was dictated by Product. It was extremely difficult to get their input on feasibility until it was too late, which led to a lot of rework. Time was always of the essence and quality suffered as a result. A lot of the developers also took on the attitude of “the product doesn’t have to be accessible because it’s just for Teammates” (actual quote!). This led to the developers feeling constantly rushed and overwhelmed with work, the PM feeling frustrated by the mounting list of bugs, and Design feeling like our work did not matter.
When I finally started working with a dedicated UI designer, we When I finally started working with a dedicated UI designer, we struggled to coordinate our work with Dev and Product. Additionally, our leadership had told us that this project was the top initiative for the year, but we lacked the support and the authority to enforce one of the core goals of our design department, which is to deliver on a quality user experience. This led the PM to believe that we were perpetually falling behind and to the developers believing that we lacked the necessary understanding of the technical limitations and were instead pushing for an idyllic solution.
Trial and error → a way forward
Finding common ground
It became clear that the throughline that connected us through all of our our conflicts was a lack of trust and transparency. Over the next few months, I championed several different techniques to address the following areas:
• work visibility (who is working on what?)
• strategy and planning (what are we doing, why, and how?)
• autonomy and ownership (who is responsible for what? who gets the final say on X?)
• teamwork (no more finger-pointing/Blame Game)
Some activities were more successful than others, but with each one we tried, we learned more and more about what we each needed as members of the team.
What's working today (and why)
After the merger with BB&T, many teams and projects got restructured, reassigned, or built from scratch. In my teams' case, our former PM is now the PO, we have a new PM and scrum master, and we are working with a new UI designer and researcher. We also now have a Technologist to builds proofs of concept and collaborate with the front-end developers.
That said, most of the techniques carried over through the team re-shuffling and the merger and are now key activities in our process. Here's why they work:
Open, honest communication
I led the charge of radical candor by showing and sharing with my teammates how to approach problems within the team. We committed to working out problems among ourselves before involving our leadership and to being open about what is/is not working and where we need help. Over time, people got more comfortable about voicing concerns and working together to address them, and now this is one of the hallmarks of our team.
Frequent (~daily) UX/Product chats
As an offshoot of open and honest communication, I Slack with my PM and/or PO throughout the day or every other day to get updates on product direction, dependencies, and timelines, and to share updates on design direction and get ad hoc feedback. We also use those opportunities to laugh about whatever crazy thing has happened that week (or day...or hour). This helps keep us all in-the-loop as well as maintain solid working relationships with each other.
This was one of the first major process changes that I pitched to our team. We maintain two tracks of work, discovery and delivery, while avoiding the common issue of disengaged developers and a clunky designer-developer handoff. In both tracks, Design and Development consistently work together, but we are no longer designing the stuff that the developers are building within the same iteration.
Instead, we involve all disciplines (Product, Development, and Design/Research) at all phases of the project and prioritize the tactical design work such that all team members can work in parallel. This gives the developers time to consider feasibility, think about how backend choices will affect user behavior, and contribute to the product functional design before they pull the work into a sprint. This workflow also allows Design to work at least one sprint ahead of Development conducting research, iterating on designs, getting feedback from other designers, and testing prototypes as needed.
UX grooming and planning
To enable the dual-track work, we have a weekly UX grooming and planning meeting that coincides with the start of each sprint and midpoint. We use this time to review the backlog, get answers to questions about stories from a design perspective, and then pick up that work for that sprint. I invite the Dev leads so that they can listen in on the discussion between me and my PO, field any technical questions that I might have, and be aware of the stuff that Design will be working on.
Combined scrum board for Design and Dev
Initially, we tried having two separate scrum boards. One for Design/Research and one for Development. We did this for a few months, but the developers and scrum master never really looked at our board when they wanted to know the progress of design work. The company switched over Rally, and we used that opportunity to re-structure our board to include research, copywriting, design, and development columns so that we can represent the full flow of work and so that the whole team has visibility on what is being worked on.
Iterative user stories vs. kitchen sink stories
My PO used to co-write monstrously detailed and prescriptive user stories that were extremely difficult to understand. I worked with him on taking a more iterative approach to story writing so that he now adds detail over time as we groom the stories with the team. The first iteration gets shared in the UX grooming session at the start of each sprint and gets refined as the design and other details related to the story get fleshed out. This saves my PO time in the long-run and has greatly reduced the amount of confusion we used to face when attempting to groom stories.
Product and Dev involvement in user research
We began inviting the developers to user testing sessions and sharing our findings with the full team so that they could be involved in the research efforts and see how the findings connect back to development work. I also started memorializing my past discovery research and being more deliberate when using that data to buttress my design decisions. Today, the developers, PM, and PO now consider research to be an integral part of the product development process that may, indeed, slow down work from time to time. This is a huge win.
Developing this process was challenging, no doubt. But the experience is unrivaled and the effort has paid dividends. We are now a top-performing team within our line of business, and I have been working with other designers to implement similar processes within their respective scrum teams.
In a year’s time, we have evolved into a team that shares ownership and that has been successful in following a more substantial design and development process. We still have our good and bad weeks, and there will always be room for improvement, but we have made great strides and can only get better.