Agile Design : Fact or Fiction?
Agile has become a more widely adopted workflow for technology teams in recent years. The agile framework emphasizes the value of individuals and interactions, working software, customer collaboration, and responding to change as a basis of success. This sounds appealing to designers, but there can be friction in knowing how to participate, especially when most agile teams talk more about stories, ceremonies, and velocity than the four core ideas from the Agile Manifesto.
Tactics for Collaboration
Collaboration should be at the heart of agile. If your team cannot come together to solve problems, it becomes impossible to iterate quickly or accomplish sprint goals. Here are a few tactics that can help us work more effectively together:
Cross-discipline collaboration.
Finding ways to collaborate across disciplines will reduce the ‘mini waterfall’ effect most agile teams fall into. This means having developers participate in the design process through sketching, prototyping, and participating in usability testing. Likewise, bringing designers into the development process with frequent check-ins, discussions, and planning can ensure that everyone knows what we are working towards and why. Building collaborative teams takes time, but getting started can be as easy as getting others involved in the design process.
Team based estimation over task based estimation.
Team based estimation focuses on the effort of the whole team, not just design, to complete an objective in a sprint. It can be challenging to think about the effort of the whole team to complete a task, but it creates a framework to make the whole team accountable to the outcomes of the work. When using this method, effort should be represented in one whole number, not just the sum or average of everyone’s individual estimates. This approach can help keep teams accountable to collaboration and ensure everyone stays involved.
Group sketching.
Sketching allows everyone, including developers, product owners, and design, to rally around the problem and ideate on how we can solve it. Try to sketch at a high enough fidelity that the team can start either coding or documenting decisions. Ideally, the team should come out of sketching with clear focus on how we may tackle the problem. If you don’t end up with what you need to move forward, create action items to research or test an idea before the next session. Sketching should build understanding and alignment with the team so no one is waiting on UX to “design it” so they can get started.
No handoffs.
Wireframes should exist to document decisions, not be a blocker to starting work. One way to keep things moving is prototyping in code, not in design tools, as much as possible. Additionally, checking each other’s work through visual QA, sprint planning, backlog grooming, and collaborating on acceptance criteria can all help teams work together, across disciplines, without handoffs. If some of these don’t work for your team, that’s ok. Find other ways to ensure your team is consistently communicating and sharing ideas.
Tactics for Communication
When discussing agile with designers, I am often asked “how do we communicate design to everyone else?” It is important to remember that being a good designer doesn’t mean knowing all the right answers or bestowing your views on everyone else. Being a good designer, and a good leader, means facilitating conversation and knowing who can help solve a problem. Although this can be challenging for a variety of reasons, there are tactics that can help:
Outcomes over artifacts.
As much as possible, put a workflow in place where developers aren’t waiting for designers to “design it”. Design artifacts should be robust enough to capture requirements and build acceptance criteria, but shouldn’t be the primary method of directing effort. Instead, try focusing on sketching as a way to build understanding and next steps for your team.
Clear, transparent, and accessible requirements.
Consider keeping annotations and requirements in a central place with wireframes, visual designs, and other key information. Using Sketch or a content tool like Confluence can make this easy. Reducing the amount of documents someone needs to find in order to see the whole picture will ensure everyone has the most up to date information.
Consider version control using a centralized tool.
Version control makes it easy to find the most up to date documentation and track changes which can greatly streamline communication. Design version control tools like Abstract work well with Sketch. If you can’t get your whole team access to Sketch, consider tools like Figma or Zeplin.
Maintain your garden.
No matter what tools you choose to use, make sure your documentation and requirements live in a stable, accessible, and centralized location. As a result of this effort, everyone should know what decisions were made and how. It is also important to keep a cadence for updating documentation and communicating out important information. Finally, make sure you allow time for feedback and iteration as part of your documentation process.
What agile really means
Adapting an agile design and development process takes consistent iteration. Each team will have their own unique needs and not all tactics may work for your team right away. When working within agile, the tactics aren’t as important as these outcomes:
The product knowledge lives with the whole team.
When you work as a collaborative team, everyone has a chance to contribute and share ideas. Anyone on the team should be able to speak to a decision or requirement. It is easier to stay focused on outcomes when we all know what is driving our product decisions.
Build a culture of shared ownership.
Everyone has different skills and perspectives that make a product better. As much as possible, ensure the product knowledge and strategy lives with the whole team. Anyone on the team should have the power to contribute to or make decisions.
Aim for iteration and learning, not perfection.
Agile is a great framework to keep your workflow lean and create opportunities to test often without letting scope bloat out of control. Research and user testing doesn’t just need to be a design activity, either! Invite developers, product owners, QA, and other team members to participate.
Emphasize clear and frequent communication.
Ensure all necessary members are a part of important conversations and you are frequently sharing decisions, new information, and outcomes from discussions. Not everyone can be in every conversation. Take steps to make sure documentation is easy to read and find.
Agile is a process that goes beyond ceremonies, stories, and stand ups. It is about communication, collaboration, and iteration. Take the time to reflect as a team and make adjustments or celebrate what is working really well. Much like the agile process itself, these ideas are meant to be a framework or basis to grow your own practice of agile that is inclusive of all members of your team.