Splitting UX/UI from Development is an Anti-Pattern
The product we work on (a mobile game) depends on graphic designers to design and create artwork that goes into the user interface. We are working incrementally on new features for the game, and each new update contains roughly one significant feature. Graphic designers work one sprint ahead of the developers to avoid too many dependencies during the development sprint.
No! Bad agilist! Go stand in the corner until you are ready to offer contrition for the error of your ways. (NB: Just teasing. Your question is asked in good faith, but I just couldn't resist the metaphor of an ersatz agile approach being a punishable offense.)
First of all, your organization is currently conflating "updates" shipped to the end user with the potentially-shippable increments of work that agile frameworks focus on delivering within a sustainable and predictable cadence. This is one of the reasons your UI/UX work seems so large: because your increment is not really as incremental as it should be!
It's tough to talk about "agile" in general since it's simply a set of principles, so I'll focus on leveraging a specific framework like Scrum. There are certainly others, and they often share many similarities. One such is the goal of using features, users stories, or backlog items that meet INVEST criteria.
Applying INVEST to Your Process
Your current process violates at least two core principles of the INVEST mnemonic:
- Your updates are neither small nor estimable.
- Because you're treating an update as a whole unit rather than independent or negotiable increments, you can't really ship part of an update. That forces the team to do big, upfront design.
- In turn, big upfront design (unlike emergent or just-in-time design) results in an inability for UI/UX work to take place in the same iteration as the actual development work.
I would bet you an overpriced Starbucks coffee that this results in a lot of work being "tossed over the wall" between your designers and engineers because you're forcing them to work in separate layers rather than side-by-side. Many people under-estimate the powerful heterodyne effect of UX/UI designers working with architects and engineers instead of treating them as downstream implementers.
When people work together, agile magic happens. Consider the following (admittedly contrived) example, and then be honest about whether you're gaining the benefit of it with your current process:
Designer: Here's a mock-up of Huge Gender-Neutral Hero's new Sword of Destruction, which changes color every 1/16th of a second.
Engineer: Um, our rendering engine is optimized for only 30 frames per second in 24-bit color, so 32 color shifts each second will cause a lot of screen artifacts and noticeable tearing.
Product Owner: Plus, I talked to legal about it, and they say that even if the engineers can jack up the frame rate, the strobe effect would force us to put seizure warning labels on the product. We'd prefer not to do that.
Designer: Huh. I didn't consider those things. What if we just make the sword a more static rainbow-colored sword. I don't know; maybe we could use Pride Flag colors, and make the game more inclusive?
Engineer: We could do that pretty easily. It would probably only take a day or two to add a new skin for our two-handed battle sword.
QA Person: That would be awesome! If you could do it that quickly, we could have it play-tested before the end of the week and make sure it doesn't unbalance the game!
Now contrast this with the (unfortunately not atypical) downstream implementation approach to UX/UI:
Designer: Here's a new design sword design. Go implement it. Let us know in a couple of weeks or a month if you incompetent programmers can't make it work, and we'll carefully ignore the fact that we didn't take any of the game's constraints or market considerations into account when we tossed this work over the wall to you.
While this is obviously meant to be an extreme set of examples, the point is that Good Things℠ happen when everyone involved in a project collaborates and contributes from their own areas of expertise to the whole. This is part of how complete, cohesive increments of potentially-shippable value get built within a single iteration, rather than across multiple iterations with a lot of siloed work, excessive hand-offs, and high levels of process friction.
How to Get There
It's easy to tell people when they've wandered away from Core agile principles, or even to illustrate better alternatives. However, real organizational change is hard. To get there, you need everyone within the organization (and especially the folks in your two teams) to clearly identify what pain points the current process is causing them, and to show how invested they really are in fixing the process problems together rather than finger-pointing.
I'd start from a business perspective to see if there's sufficient organizational appetite to create measurable improvement. If no one at the senior leadership level is truly interested in sponsoring or supporting fundamental process change, the tone at the top can kill any chance at significant process improvement before it even starts. Without committed leadership support, the budget, resources, organizational structure, and company culture will simply not be available to bring about meaningful change.
Secondly, I'd make sure that the teams (plural, in this case) see value in actively working together. It won't happen all at once, so all the stakeholders involved in your company's game development project will need to buy into the need for real process change. They will also have to accept some responsibility for changing their own expectations and work flows. Without sufficient buy-in from everyone involved, the hard work required to change how the product gets developed, building collaboration, and removing muda, mura, and muri from the development and delivery processes will simply become "someone else's job." If that happens, the whole exercise will fail to gain traction and nothing will change.
The only way the full benefits of an agile transformation can be realized is through a process of continuous improvement that involves everyone from senior leadership on down to the individual teams and project contributors. The job of an agilist is to help the organization and the people involved recognize that change is hard, nothing good comes free (TANSTAAFL), and that everyone needs to be working together to make measurable improvements.
So, create awareness and buy-in first. That's the only path to real improvement. Anything else will simply be another layer of Agile in Name Only℠, and by asking the original question as you did it's clear that you already have enough of that in stock. You definitely don't need more!
