As a UX Developer, the subject of collaboration is near and dear to my heart. What I have outlined here may not apply to everyone, but I would like to share my personal experience with UX, development, and agile scrum practices, including some challenges I have faced during my six years in the industry thus far and how to address them.
I have had the pleasure (and, in some cases, admittedly, the frustration) of working in a variety of scenarios, over the course of my career, including:
- directly on a UX team,
- as a UX resource allocated to one or multiple project(s),
- as a developer working on a scrum team while keeping in close contact with a UX team or team member(s),
- as a developer working on a scrum team with limited contact with UX designers external to my company
Again and again I have seen the same questions arise in each of these scenarios. How does the UX design and development process “fit” into an agile scrum practices? How can UX and development best work together? Today I’d like to review three issues that I’ve encountered over the years: cross functional teamwork, timing, and silos.
Cross Functional Teamwork
One of the founding tenets of agile is a self-organizing, cross-functional team. This usually viewed in terms of “T-shaped” skills — facets of knowledge that are both deep and broad. An agile team member should have a deep knowledge of a particular subject area, whether as a developer, UX designer/analyst, or QA analyst. Regardless of their role, as the scrum team matures, each team member should have a broad sprinkling of a few other topics in their arsenal. If their “T” is a little narrow — and this is perfectly normal in the early stages of a scrum team — they should be open to expanding their horizons as the project progresses.
The best teams help one another learn skills. Most designers I’ve worked with have had at least a basic understanding of HTML and CSS — enough to know what was possible in a web environment. The best designers I’ve worked with had a solid understanding HTML and CSS. Beyond offering a few specs here and there, these individuals were capable of fully bringing their designs to life within a development environment through their markup and styling skills. Some were even proficient in JavaScript, PHP, or Python.
This doesn’t have to be limited to development, either — UX can also participate in quality assurance, providing visual QA to ensure that the design was implemented as intended. At the same time, developers can take part in usability tests as observers, notetakers, or even help to coordinate and conduct tests themselves.
This will of course require training and reading, along with an open mind and a good pinch of humility. The worst thing a scrum team can do is to isolate their knowledge between subject matter experts. A “holier than thou” attitude from any side will only serve to create barriers and delays. Although you may experience some slow-down in the short-term as team members learn new skills and techniques, the long-term benefits will greatly outweigh the initial bumps.
Cross-pollination is vital to the success of a scrum team. When team members share their knowledge, they learn how to collaborate more efficiently and can more evenly spread the load of the user stories amongst themselves during the course of a sprint.
This isn’t to say that everyone on your team should be able to do everything — a designer probably won’t be constructing your models in your ASP.NET application and a developer likely won’t be creating high-fidelity comps in Photoshop from scratch. However, knowing a little can go a long way in saving time. Plus, you’ll be creating a well-rounded, tightly-knit team that can work well together and produce consistent results.
Timing Is Everything
There are three scenarios to address when considering timing and UX involvement.
- How should UX work with a development team at the beginning of a new project?
We’ll call the answer to this the “discovery phase.” - How should UX work with a development team for an existing project?
The end-goal should be to allow UX to work in advance of the development team. - How should UX work with a development team after completing the initial designs?
The work does not stop here.
Discovery Phase
When possible, I am of the strong belief that UX should begin their work early, during a “Sprint 0” or even earlier. This is not a new concept. Technically, all areas of a project team should have a “Sprint 0.”
For Development, it’s establishing frameworks and spinning up the development team around any new tools (such as build/deploy) and architecture.
For QA, it’s reading the requirements and questioning management and the dev team, building initial high level tests, and developing testing frameworks.
For UX, this means ironing out project goals with product management, interviewing users, creating personas, and potentially sketching out ideas.
This all fits under the “discovery” phase, which is the initial sprint (or two, or four) of a project.
Two Sprints Ahead
The sooner the the better, because ultimately, regardless UX should aim to work at least one to two sprints ahead of development.
“But Mandy!” you cry in alarm. “That isn’t agile at all! Isn’t that the same as developing two sprints ahead of testing?”
No. No it isn’t.
Let me explain.
UX must view the project from a higher level, on par with product management. The result of a UX process is not only a design, but a overall view of the entire workflow, from a user’s motivations down to the completed application. This holistic view calls for iterations that begin before development to allow time for shifting requirements and additional usability testing that may result from said changes. UX should continue to stay ahead of development after the initial few iterations for new features and maintenance.
The UX process as a whole is just as intricate as that of development. The Adobe Blog outlines five key phases of the UX process. While this process could be accomplished in a two-week sprint — or even as little as a week, in the case of Google Venture’s design sprint — this leaves little time for development and QA, especially if user testing reveals additional issues that the team must iron out before beginning development.
Therefore, it is critical for UX to get ahead of the game and work with product management early to allow for several iterations prior to development for each user story. This saves time on the development side and ensures a high quality, user verified product.
Implementation and Beyond
Equally, UX should also continue to work with the team during the implementation process, after providing the designs, to ensure that there are no issues with development, and also afterward, to conduct further tests to ensure that the finished product meets user expectations. UX work does not conclude once the designs have been passed on to the development team — if anything, this may be when the team needs its UX resource most. Designers and analysts should be available for follow-up iterations and avoid a waterfall-esque “hand-off” of the designs to development and QA.
Silos Are Deadly
One of the most dangerous things a scrum team can do is isolate their designers from their developers. This is particularly troublesome in a services environment, where each step of the application is may be contracted out to different firms for project management, design, development, and testing.
Developers, if you can, get to know your designers — and vice versa. The first time a developer hears from a designer should not be when the designer posts a screenshot to the developer’s Jira ticket. Have a quick meeting when a new developer or designer joins the project to introduce them to the team and make sure there is a clear channel of communication, whether through Slack, Microsoft Teams, Google Hangouts, Glip, email, or some other medium, with a preference toward more immediate feedback (email being the least ideal).
An aside: The most ideal form of communication is when everyone is on the same tool. UX should not be using Glip while Development is on Slack and QA is on Hangouts. Using different tools creates an unnecessary barrier for communication (this sounds obvious, and yet I have been there).
In an ideal world, I believe each scrum team should have an embedded UX designer, analyst, and/or researcher working long-term as a member of the scrum team. This designer should still keep in touch with the design team as a whole (using a Community of Practice model), but should work most closely with the scrum team. This harkens back to my earlier point on cross-functionality. Team members with varied roles who work together will learn much more from each other and grow as a group than if they are separated into their respective teams with less frequent direct interaction.
What can you do when it is not feasible for your designer to be embedded on your project team? The answer is simple — design meetings. These don’t have to be a frequent occurrence and your entire development team does not have to attend. Send a developer or two with a particular interest in the UI to sit in on a session once a week or even twice a month and have them bring back meeting minutes to the rest of the team.
In attending regular design meetings, your developer will have the opportunity to ask questions, give feedback on the design, and bring up any current issues with implementation that would have otherwise had to go through your Scrum Master, Product Owner, or Project Manager. Although it can be important to keep your PO, PM, or SM in the loop, too, when your developer just needs to know what color the hover state of a link is, why play a game of telephone when you could talk with one another directly?
Summary
Agile is often spoken of as having a “Three Musketeers” attitude — all for one and one for all. UX and development work best when they consult with each other to expand one another’s skill sets, begin working together early on in the process, and have clear lines of communication. This may not be easy or even possible in all scenarios, but if you are to take away one thing as I stand on my soapbox here, it should be this: encourage teamwork for best results.