June 18, 2018
A common problem we face is how to organically fit processes that are not part of pure software development. Here, we tell you how Agile and UX design can work together.
Many of you already know what Agile is (or Scrum, its most popular implementation), its main benefits for software projects, and its main values (the Agile manifesto makes it pretty clear). But a common problem we usually face is how to organically fit processes into our daily routine that are not part of pure software development, such as UX/UI processes.
Next, we are going to delve into some concepts that will help us understand why it is not necessary to force this practice artificially within our Agile process, but on the contrary, it must fit naturally into it. How do you do it? Let’s take a look at the following:
1. They are part of the team
Generally, a Scrum team is made up of a relatively small group of professionals (between 5 and 9 people), which is multidisciplinary and with the necessary skills to carry out a specific project.
That does not mean that everyone must be a Senior and therefore, be capable of doing everything (from programming, to testing, or configuring the continuous integration server, among other activities). In general, most professionals end up specializing and deepening their knowledge in some subject area (front end, back end, etc.).
However, if a software project needs a good user experience, usability, and design, we will most likely think of a UX designer, a person who, although not directly related to the development, has to clearly understand the objectives and vision of the project.
As a key player in the whole process, the UX designer must therefore take part in the Scrum ceremonies (Dailies, Plannings, Demos, Retros) like any other member of the team.
A designer will then perform UX tasks in the same way that a developer does development and architecture tasks or how a tester does the testing work. A good self-management of their different tasks and dependencies is necessary in order not to generate bottlenecks.
2. Bus factor
One thing to consider is whether the team configuration passes the bus factor. It is a rather crude test but with a clear message: How many members of the team must get hit by a bus before the team stops working? The lower the number is, the worse, as it means that the team’s know-how is not well distributed and is concentrated in few people.
If a team member is missing for any reason, it can generate a problem in achieving the Sprint goals. Since we probably have few UX experts on the team –depending on the type of project– this could be a risk factor if we are not prepared.
How can we prevent this from happening? There are many ways to do it. One is to ask the designer to document the design standard so that it can be consulted by another member of the team if necessary. In addition, the designer can carry out some tasks with another member who is interested in learning or who has a penchant for UX, ensuring that in the case the designer is not available, another person covers his or her work. The important thing is to prevent the development from being held back.
Implementing these actions creates a more natural integration of the designer with the rest of the team by making him or her part of tasks implemented by other members.
3. Design before development
Most design and layout tasks are very likely to be carried out prior to the development, which is why it is natural that they are implemented in separated Sprints. Doing this may seem like we are going against one of the Scrum rules that refers to adding value in each Sprint and implementing something potentially deployable at the end of it.
A wrong comparison is with testing tasks, which are ideally carried out during the same Sprint as the development.
If something is not tested, it will probably not meet the Definition of Done, which is why we cannot consider something finished if it must be tested in the next Sprint. The difference here is that the design and layout tasks could be considered analogous to definition and analysis tasks, as they are part of the discovery process and specify how a functionality will interact.
It is not recommended to do the design and layout during the same Sprint as the development because they require customer feedback and can drastically change the direction in which it goes. If we start the development at the same time as the UI design, we will probably have to undo a lot of work.
To Sum Up
Agile is an adaptable work scheme with no prescribed rules that say how things must be done, but a set of good practices as jurisprudence does exist.
In this scheme, we cannot underestimate the importance of UX and UI, as they are an essential part of software, and as such we must find the way to make them part of the development processes, just like testing or programming do, with all of these integrated in the most natural and organic way possible.