How Agile Can Facilitate Design and Development Cooperation

Is a truly Agile approach to Design possible? We share the road to our design process.

How to make design and development cooperation during projects run smoother with Agile? Our process is based on the approach we adopted during the newonce project that started before the pandemic and needed to be rescoped during COVID-19.

Agile in Design

Can Agile and design even work together? You are probably familiar with the Agile Manifesto. Let me ask this: does it even mention design at any point? Well, not really.

That's probably why most designers—when asked about working in Agile—react like Admiral Ackbar in Star Wars ("It's a trap!"). And they do have sound arguments against it.

Designers need to look at the product as a whole. Otherwise, we might end up with something looking like Frankenstein. Another logic is that there won’t be time for testing or revisions. When starting the design phase simultaneously with the development, the time is tight. We definitely need to focus on delivering the resources for developers from day one. It pretty much limits our time for all those good practices during the design process. On the other hand, in Agile, we should spend dozens of hours on those strange retrospective, planning, and grooming meetings.

Knowing all that, it's hard to think that Agile and design can go hand-in-hand. We thought the same at EL Passion.

Since design and Agile—especially when it means Scrum—cannot get along, we, as designers, decided to focus on what matters to us and comes before development. It basically means the design process. A process that enables us to use all the good practices and design awesome products without developers pushing for deliverables from day one, without all these Scrum ceremonies. And, with all due respect, without JIRA.

To be honest, we pretty much succeeded. The designs handed to the devs were awesome. Market fit, checked; user tests, usability testing, groundbreaking usability based on those tests also checked. Also, pretty interfaces (just check our Dribbble).

The clients loved the deliverables that we showed them at the very end of the process. We were satisfied and loved our work. You probably suspect that there is a “but” coming. The “but” is that the final products we delivered were good, but they were not as good as it gets. Although our design process was so Lean and the development process so Agile, we ended up with a beautiful, but nevertheless a waterfall.

Design-Development Handoff

The design-development handoff in this setting can quickly turn into a disaster. Why, you ask? If we have all the development and design processes in place, if we test it, if we are sure about the market fit, why can't we do things like this? Well, the answer is change. Everything is changing, especially in six- or 12-month long projects.

Requirements can change, budgets can change, or even user needs can change. You know all that, so let’s use a real-life case study here. COVID-19 struck in the middle of cooperation with one of our great partners, newonce, a Poland-based modern media group, bringing together written journalism, a radio, and a podcast-on-demand hub. The new situation necessitated changes in the budget, timelines; the client's users' needs also changed.

Changing scope and budget were not the only issues in the project. It was really complex; there were two services: newonce sport and newonce.net, working in both light and dark mode. Thus, apart from the marketing issues, we were facing many technical difficulties that we haven't been working on before.

As the pandemic struck we were just after the design phase, starting with the development. The problems with our waterfall handoff became more apparent as the scope needed to be adjusted significantly.

Something needed to be done.

We started examining different approaches like the straightforward merging design with Agile and beginning the design and development simultaneously.

Every sprint, the designer would prepare UX strategy for a particular module, design the wireframes and put a UI layer on top of that, while the developers would start to develop... After just five minutes of thinking about it, we decided it won't work at all. Why? Because we are getting into the actual Agile trap, we discussed at the beginning. We won't have enough time for testing. We won't have enough time to put attention to our craft, and the developers won't have the stuff to work on because we do need time to design something.

We started experimenting with potential solutions for this project, and we came up with Sprint 0. We'll start with fundamental design work at the very beginning. Then, we'll incorporate the development into the process, working on both simultaneously. It is definitely a better approach than the one that I described initially, but it's still very time-sensitive. There is a lot of pressure for designers to deliver, maybe not from day one, but from day 15. We still are risking that we will end up with something looking like a Frankenstein because we are focusing on small parts of the project, which are older at the end of development, rather than looking at the big picture.

Our Agile design process

The process was being refined in real-time, and at the end of the day, we were able to release the newonce project on time. The release was a huge success.

Now that the dust has settled, I had time to reflect on how we managed to deliver the newonce project amid COVID-related scope changes. If it was a chart, it would look like the one below.

The reason I’m coming back to the newonce project is that we started it with the old process and ended with a new one. In hindsight, the process that continually evolved during the project is now our default approach to product development. And it looks like this.

We start with a workshop, taking place before the project kick-off. The workshop includes both developers and designers on our side and product owners and decision-makers on the client's side. If you would like to know more about the value of workshops, I recommend an article on why your product needs a design workshop.

During the workshop, we align our expectations and what in general, the product should look like. Then, we start with sprint zero, which is a very different sprint than the rest of them. We focus on the whole picture. We design the architecture of the entire product without spending too much time on details for specific modules or features. We don’t even touch the UI.

In Sprint one—which is significantly shorter—we start working on specific modules a week or two ahead of the development team, without losing a bird's-eye view on the project.

We are getting into a different module every next sprint while developers code the stuff that we designed previously. Obviously, it isn’t like design and development go their own way. We have joint meetings, attending daily stand-ups, so we actually know exactly what's going on in the development and design. We are communicating a lot between the teams. But it isn’t like the designer is a part of the development team, and we are working together on particular features.

That being said, I have to underline that this approach would not be ideal for making a product better; but more for when we’re designing it from scratch. It’s an entirely different story when we are thinking about extending a mature product, which has been on the market for quite some time.

Agile Design Process Requirements

The Agile process we’ve come up with works. It's definitely not all roses, though. This approach requires a few things. The first step is educating clients about Agile.

It's not possible to work in Agile without any kind of flexibility. If the client wants to know a strict budget from the very beginning, there's no way you can even think about implementing Agile. Agile requires flexibility. It's impossible to have a fixed scope or a fixed budget and work in Agile. Still, money is always an issue, so it’s not about having an unlimited amount of it, but rather making the most of what you have, and maximizing the end-product business value.

This approach requires a shift in the way we think. There are no development or design goals. There are the product goals, and we have to be open to compromises on all fronts.

As a designer, you cannot focus solely on designing a usable experience for the user; you need to be aware of the technical constraints involved in the development in particular technology.

Last and not least, Agile is an iterative process. The team needs to embrace iterations. There cannot be an approach like, "I developed it already. I won't change it." It will basically make the whole team fail. If we decide that we design a product as we go, you need to keep in mind that some things that were designed previously will definitely change because when you go to feature five, you'll come up with a much better pattern, which needs to be applied to the rest of them.

The most crucial point that you need to keep in mind is that Agile is not a comfortable experience. A true Agile is far outside every designer or developer comfort zone—devs will need to rewrite code. Designers will have to make compromises in design and redesign a lot of things because at the end of the road, there's the working product.

Knowing when to apply Agile in Design

• Even before the methodologists process everything, there's common sense. You really don't need to set up JIRA for a five-day-long design-only project. Designers don't have to be present at every grooming, planning meeting with the developers. Based on my experiences, the designer's input is limited to answering one or two questions in most such cases.
  
  
• Communication is key. No process can replace communication or human interaction. Even the best JIRA board or development, process, or handle service won't replace a need for communication between designers and developers, and clients.
  
  
• There is a life without Agile. Not every good digital product needs to be developed with Agile. For example, I cannot imagine using Agile while working on a three-day project to release a simple marketing landing page. You need to also keep in mind that this applies only to small projects which are not subject to many changes.

Check out also

• CASE STUDY: Redesigning newonce.net - A Lifestyle Platform Celebrating Youth Culture to see how changing our approach to the Design Process gave birth to one of the top lifestyle platforms in Poland