Designers can’t stand flexible methodologies. And also daylight, 5/2 working week, task trackers and everything that interferes with the freedom of creativity. But if they were given free rein, many would postpone all work for the last day, the last night before the deadline. And then in the morning, with red eyes and empty energy drinks cans, they presented their brainchild (and not the fact that it was successful).
Therefore, the framework is still needed (for their own good). Another question is that it is not easy to integrate design and UX into Scrum and Agile due to the peculiarities of the design process: this topic is somewhat holivary, and causes difficulties even for experienced practitioners. Although there are still a couple of solutions – which ones, Grentana specialists will talk about in this article.
Integrating Design and UX into Scrum
Design and UX are the last things its creators intended to use Scrum for, so practitioners with many years of experience sometimes still wonder about their integration into the scrum process. The key reason for such difficulties lies in the very idea of the framework: it was created not so much to make the product more customer-oriented (for which, in fact, design and UX are responsible), but rather to speed up development.
But some teams manage to overcome this contradiction and build the design process within the Scrum organically. One of the solutions to the problem is to carefully overlay design and UX activities on top of the scrum model. The result may look something like this (the original diagram is taken from Jeff Gotthelf):
Jeff consciously makes some assumptions and somewhat simplifies:
- provides a far from exhaustive list of design activities;
- uses the word “Design” as a general term for all kinds of design activities for designers of all stripes;
- does not dilute the concepts of “Design” and “UX” too much, offering to discuss it sometime later.
For each group of UX-activities, the author of the scheme gives explanations:
1
Product backlog
It contains theses of a broader vision of the product, which are not planned to be worked on in the current sprint. The fundamental ideas, vision and hypotheses are all here. Activities like “Design sprints”, “Research” and writing hypotheses help to give the elements of the backlog both reality and customer orientation.
2
Sprint planning
Daily team “routine”. An approximate range of questions: “What will it look like?”, “How will the user move from screen to screen in the product?”, “What exceptions will we have to deal with?”. In search of answers to these questions, you can use design tools — for example, joint sketching or collective brainstorming, which UX designers love very much.
3
Tactical Design (the whole variety of product design is hidden under the big letter D)
It should be embedded in the sprint backlog and performed, first of all, by designers, but without interrupting the scrum team. The idea is to prioritize this work so that all team members can work in parallel.
4
Full-time designer in the scrum team
According to the classics, he is absent from the scrum team, but for the integration of UX design into the scrum process, according to Jeff Gotthelf, he is needed there. Why is that? Only in cooperation with developers, product managers and scrum masters can a suitable tactical design be obtained.
5
Sprint Review
This is an opportunity together with the team to look at the result of the work created during the sprint. The review also makes it possible to review what the team found out during the sprint (and what was the result of these discoveries). Design review, search synthesis and qualitative analysis give an idea of the further progress of work and help to prioritize both products and the next sprint.
The author of the scheme, Jeff Gotthelf, is sure that design and UX can exist in a scrum system only if the designer is on the staff of the company – with outsourced guys, sooner or later everything will end with a waterfall model.
Integration of design and UX in Agile
Agile with UX and design, in general, has the same problems as Scrum: it is easy and comfortable for programmers to work with iterations, but not for designers. Because it is easier for a designer to think through the concept completely, rather than splitting this task into smaller ones, while losing the global vision of the client’s problem being solved.
There turns out to be a dilemma: either qualitatively and for a long time (when the concept is thought out holistically), or a crude product, but quickly (when there is no time for a global vision, but the work is subject to the laws of Agile).
Actually, a compromise solution has been invented for a long time — Grentana designers have been applying it for a long time. The main idea is parallel design and development flows, where the design flow goes ahead by one iteration (the so-called “zero sprint”).
At the project planning stage, analytics are carried out, the needs of the client and the market are clarified, the structure of the future site is formed, a prototype is being developed. At the zero sprint, a design concept is created and approved with the customer. Further, programming is carried out in parallel according to already agreed layouts and the design of new pages within the framework of the basic concept.
What does this approach give?
- the inclusion of designers in flexible development plus maintaining the quality of the created interfaces;
- the involvement of all specialists and the absence of “downtime”, even if there is only one project in the work;
- regular feedback from the customer and edits at the lower levels (the earlier the problem is discovered, the cheaper it is to fix it).
The scheme has been tested in practice for years in the studio, the process is controlled, customers like the result. Although on the Internet you can find criticism of the idea of a zero sprint.
Design- and UX-spike
Adherents of the design or UX spike criticize zero sprints for the fact that designers often manage to solve only the most basic problems in the time allotted for this sprint. His other problem is that this is a one-time event at the very beginning of the project – it doesn’t really look like flexibility. There is also an opinion that the result of the zero sprint may allegedly not be enough for the development team in the 1st sprint.
Spike is an activity in Agile that helps to gain the knowledge necessary to reduce risks, better understand the requirements and evaluate the task. A spike is used when an unclear task appears in a sprint with a lot of possible problems and uncertain complexity. Instead, a spike is taken into work, that is, the work necessary to give an answer or a solution, and not to roll out a feature.
Therefore, on complex projects, they came up with interruptions for spikes. This topic is old, but sometimes it “pops up” to this day. In fact, this is additional time for research, studying information for a clearer understanding of the approach of further development and more accurate assessments of the current task.
For a design spike, an additional role is introduced – Design Owner, or Design Owner (team leader of the design department, for example). For the UX spike, respectively, – UX Owner, the Owner of the UX. This role is needed to defend UX and design solutions to the Product Owner (conflict of interest here is a fairly common story).
Such spikes are focused on design or UX tasks from the backlog – development has nothing to do with this stage. The time of such “design breaks” is not regulated in any way, but the team should strive to complete the spike as soon as possible (well, well). And of course, at the initial stage, the Design Owner or the Owner of the UX must approve the readiness criteria, upon reaching which the spike can be considered completed. After completion, the usual Agile and/or scrum process continues.
We are confident that the introduction of a new role that will argue with the Product Owner about design solutions will not solve anything. The problem, in his opinion, is the inability of the team to communicate with the Product Owner himself, and that the designer in the scrum team cannot explain what UX design is and why it is needed. So it’s up to you to decide whether to interrupt the sprint for such a dubious pleasure.
Conclusions
- To integrate UX and design into Scrum, it is enough to impose their basic activities on the standard scrum process.
- A full-time designer within the scrum team is a prerequisite for integrating UX and design into the scrum process.
- For integrating UX and design into Agile, zero sprint and thread parallelization is a good working solution (we checked).
- A design spike is a crutch for teams that cannot communicate with the Product Owner, and for designers who cannot convey their ideas to the team within the framework of a standard sprint.