Earlier this month, I received a question from a participant in of one of Michael James‘s CSM courses about how to integrate UI design into the Scrum framework. I’d already been working on a post addressing this subject broadly, but the inquiry provided an opportunity to summarize my main points while including some specific considerations for design consultancies doing Scrum while managing client relationships. He writes:
Any tips on how to integrate Scrum into the interaction design process?
We often have to deal with delivering functional specifications (including the wireframes) up-front for sign-off with the client. Call it sprint zero if you like.
I’m interested in your recommendations and experience on this.
Below is my reply in full:
There are two parts to the answer: one addressing the perceived tension between Scrum and the typical predictive process model used by most designers (analyze and design first before building), and the other addressing the dispersal of team members across organizations in a provider-client relationship.
There are a few ways to address the first:
In cases where there are large, imposing design problems that will require time, negotiation, and multiple iterations to figure out before anything gets built – say, determining the navigational structure of a new website – write analysis and design backlog items for the typical design steps, with the title or done criteria describing the artifact that will result from the effort. Here at Danube, we’ve done so by naming them “Round 1 Sitemaps,” or “Round 1 (…2, 3) Wireframes.” These backlog items rarely require the participation of every team member, but usually there are other backlog items that can be worked on by the rest of the team that don’t require the participation of people working on analysis & design. Not every piece of work in a Sprint needs to be swarmed on by every single team member.
For smaller backlog items that can be designed and built within one Sprint and do require participation by the whole team, there’s no real way around having to scale down the time allotted for design so that it’s in proportion to the Sprint. This essentially means you have a miniaturized waterfall process within your Sprint. This is merely being pragmatic, and is a workable compromise provided this approach is used in conjunction with the next technique, which is…
Get the whole team used to iterating over Sprint output in successive Sprints. Rarely is any person’s or team’s first attempt at something the best or final version, and often it’s simply not good enough. This ‘inspect and adapt’ tenet of Scrum applies as much to designs, code, or any other output as it does to the process itself. The thing to keep in mind is that just because a backlog item has been completed doesn’t mean the feature it describes is automatically now blessed as fit for release. If the output of a Sprint doesn’t yet adequately satisfy the business need or meet the PO’s satisfaction, it’s a candidate for rework. More on how Scrum roles and your duty as a designer on a Scrum team play into this decision, below.
As for Scrum roles and dispersal across organizations:
First let me say that I have yet to practice Scrum in a design consultancy environment. We’re a small corporate organization and our relationships and Scrum roles are clearly defined. I have, however, worked for design consultancies and am familiar with their particular design & development and client relationship challenges.
I gather from your statement that your clients – the ones requesting functional specifications (including wireframes) up front for sign-off – are handling the development. It also sounds like some think they’re practicing Scrum, though it’s clear from the example that they’re not, quite. If they were, then wireframes, sitemaps, and other design artifacts would be produced in Sprints in collaboration with the rest of the Scrum team. Asking that the design be finalized “up front” and then thrown over the fence to development is just more waterfall, no matter what process development uses thereafter, because the first requirement of a Scrum team is that it be cross-functional. Design, after all, is work necessary to build a website or software product just as much as programming is. Of course, we all know that sometimes design needs time to come up with something to build before building begins, but I’ve already addressed that above. My point here is that designers are equal members of any Scrum team that requires the input of design in order to complete a product. If you’re providing design, then you’ll need to place designers as team members on the client’s Scrum team. If you can’t logistically have them working in the same room with the client’s employees, you could at least have them meet regularly and participate in all the typical Scrum events such as daily standups, planning sessions, reviews, and retrospectives.
Even if your organization is doing the designing and the programming, you still need to integrate the client somehow with the Scrum framework. The client roles would certainly include Stakeholder, but possibly even Product Owner. Of course, if your client isn’t familiar with Scrum, then you’ll have the extra task of bringing them up to speed in addition to designing and coding. This presents a dilemma: The Product Owner is a pivotal and difficult role even for experienced Scrum practitioners. Do you just throw an uninitiated client into it? Probably not. In this case, the consultant account representative (your employee) would most appropriately be the Product Owner, and would coach the client Stakeholders on the process while representing their interests to your design & development team. Most account reps at consultancies already perform a similar function, but making this role official might require a level of training and responsibility they don’t currently have.
Your role as a designer on a Scrum team:
As a designer, you are an advocate for the user – the human half of the human-to-computer interface you’re building. Often, on a team of computer scientists and business types, you may be the only team member that has perceptual biases in this direction. It’s therefore your duty to argue for rework if a component may in some form deliver functionality, but fails on user criteria; Nobody else may be equipped to do so. In the end, as we all know, these criteria are almost always subjective. But you should already be used to making convincing subjective arguments for design. This skill becomes even more crucial in a Scrum environment where the pace is increased and decisions are hard-coded on the fly. Since the Product Owner is the ultimate arbiter of business value in the product, you’ll most often be making your case for design with the PO. He or she will be balancing design refinement along with feature richness, performance, technology enhancements, and a myriad of other competing factors.
And herein lies the golden kernel of Scrum for a designer: The design doesn’t have to be perfect! It does have to be the best design possible, but only in the time you have and only in proportion to the other criteria of importance to the Product Owner*. The Scrum framework inherently takes care of ensuring most of that for you. As a designer, then, your challenge becomes getting the most time and flexibility within Sprints and before the release to be satisfied that the design is good enough – good enough, that is, until the next time you get to work on it.
*There is a parenthetical thought here: that design may in fact not be important at all to your PO. Value for design is likely to ebb and flow with changing needs of the marketplace and the product. But if this is the case consistently, you as a designer may be in the wrong job. A lack of value for design may not necessarily be un-Scrum, but it could be un-you.
Download the PDF version: Integrating_UI_Design_and_Scrum