How to Keep both Dev and Design Teams Happy and Productive in an Agile Environment

When you are talking about agile, you are usually talking about the effort of the development team, organized as scrum. Without going into too much of religious controversy, scrum is simply a way for developers to obtain fixed requirements for a specific time interval, typically two weeks. Thus, for the period of the sprint, the blueprints do not change.

Now it seems natural that the design team, being as it is in the service of the development team, should be organized in the same way, around a 2-week sprint. Unfortunately, in practice, that rarely works well. There is a vast difference between the work required to design the product and the work required to build one:

1) The cadence of a typical UX design team varies significantly with the type of product and phase of the design process, but it is almost always much shorter than that of the dev team. For most of the projects I tend to run, the cadence of the most prolonged project phase (RITE — Rapid Iterative Testing and Evaluation) is more like 1-2 days, in contrast to 2 weeks typical of scrum. The design cadence is even more rapid in a startup or during the initial design phase, where it can be as short as just a few hours.

2) Developers like to work in 2-week sprints so they can focus on delivering a feature undisturbed by the requirements changes. In contrast, designers are effectively working in a continuous delivery model. To put it another way, while the development team's concern is to limit change, the design team's job is to drive change.

3) Whereas the development team focuses on the current sprint, the UX Team has to fulfill dual requirements of supporting the current sprint while also planning for a future sprint, thus frequently causing the design tasks to appear to be out of sequence and separate from those of the dev team.

4) Unless developers are doing a spike, they work only on the current product iteration, focusing on delivering working functionality, which adds customer value. In contrast, the UX team is often continuously working on at least two prototypes at the same time: the “Tactical” prototype supporting the current milestone and the “Vision” prototype supporting the future direction of the product, causing even more confusion in the order and priority of design tasks.

Does that mean that developers and designers are like cats and dogs, Eloi and the Morlocks, Elves and Dwarves? And they will never be able to co-exist together in a harmonious world of agility? Not at all. Standard tools like Jira and Rally support both design and development equally well, particularly when supported by agile best practices.

The key to success is understanding what makes each team happy and productive. Whereas developers use scrum to boost productivity by limiting the amount of requirements change in a single sprint, Designers boost their productivity by limiting the number of tasks they focus on simultaneously.

Whereas the most common project management device for developers is an agile board, the best tool for designers is a Kanban board, the favorite tool of Lean teams. The good news is that a simple setting in Jira or Rally allows the same set of tasks to be viewed as either an agile board or a Kanban board, depending on which team is doing the viewing.

Here is an excellent run-down of the features of each method of viewing tasks from an excellent article by Atlassian, the makers of Jira: https://www.atlassian.com/agile/kanban/kanban-vs-scrum

The Kanban’s primary function is to limit the number of In-Progress tasks to 1-2 per designer. The aim is to have a designer focus on a single primary task at one time, with the second task available should he or she be hung up waiting for something on the primary task.

How should you set up the Kanban board of maximum UX productivity and happiness? I'll cover the detailed run-down of the optimal setup in my future articles. For now, let me just say that I recommend creating four lists: Backlog, Ready, In-Progress, and Done. The tasks are prioritized in the Backlog. When the tasks are assigned to the current sprint, they are moved into the Ready list. Once the task is picked up for execution, it’s moved into the In-Progress list. Once the task is done, it is well Done. Once the In-Progress list is empty, the next highest item in the Ready list moves to the In-Progress list, and so on, supporting the continuous delivery model we discussed earlier.

Depending on the configuration of your agile tool, the same list of tasks can also be viewed by the designers as a Kanban board and by the developers in an agile list. Thus, both teams remain happy and productive while focusing on creating the most value together.

What about the sprint planning and retrospective meetings? My recommendation is for both UX and dev teams to focus on and prioritize the tasks demanded by the current sprint. Thus there are no separate sprint planning and retrospective meetings for the design team: there is just one set of scrum ceremonies, which both design and development teams attend. Beyond spending less time in meetings, a single set of agile ceremonies ensures that even though the cadence, delivery mode, and task lists may be different, both dev and design specialties focus on delivering immediate value to the customer, expressed as working product features. As I am fond of saying to my consulting clients, “The product is the Product (and not your wireframes),” and supporting the dev team in creating the working product should be the primary focus of the design effort.

How do *you* keep your UX and dev teams happy? Which #DesignOps tools and best practices do you find most useful? Is there anything in your current product design or development process causing friction, inefficiency, or pain? Which DesignOps topic would be most helpful to you? Let me know, and I will do my best to write up some tips on the topic. Happy development!