I am not an expert in agile methodologies. My background mostly consists of designing for small companies, agencies, and startups. In each of those environments, I worked with managers and creative directors who used agile terminology loosely. However, our work mostly fell into the waterfall process.
When I started working at IBM Design in November 2015, I started to adopt agile methodologies into our day-to-day workflow. Under the guidance of Matthew Cunningham, we slowly introduced principles and practices that helped organize our design team and align with product owners and developers. Here are the three lessons I learned from my experience of using agile methodologies with my design team.
If you’re completely new to agile, check out the blog Agile For All to learn the basics.
Lesson 1: Focus on organizing time to optimize communication and output
The single focus was on the relationship between the organization of time and communication and output. When I first started at IBM, we were two years into an organization wide design transformation. Change is great, but friction is inevitable.
Designers joined a company that was trying to create a culture of design from the ground up. At the same time, it wanted to change practices that were typically developer driven.
We felt like we were designing for quick releases, but we didn’t know the direction or vision of the product. So, we made poor UX choices and compensated with quick, unsustainable hacks.
Lesson 2: Start with organization and communication
Organizing Files, Sprint planning and Sprint boards
The first priority was to establish house order. We started with planning and prioritizing our sprints in tools that gave visibility to the whole team. In our case, we use Box for notes and Zenhub for epics and stories. Product owners prioritized the epics. Teams wrote the stories. Everyone agreed on the sizing or the amount of effort required. After planning day, no one can add stories to the sprint. If there is an emergency, then the team has to agree on what story gets removed.
Designers have the opportunity to help build the vision. We just have to step up
In the beginning, communication was chaotic. We piled into rooms with our developers on the phone. Everyone took turns giving feedback for either designs or implementation. Feedback often conflicted. This often resulted in drawn out meetings, miscommunications, churn and a breakdown in trust. I pushed for internal reviews with designers first. This is a highly facilitated workshop where we create a safe space for everyone to give feedback. The designer can walk away with clear next steps. For details on how I do feedback sessions, check out this post.
Design Feedback sessions IBM Design
I also encourage the designers to reach out to the developer that requires screens early and often. In these conversations, designers and developers discuss and share notes, sketches, and any work at any stage for checkins and clarification.
Lesson 3: Leverage Agile Methodology to get a seat at the table
By getting ourselves organized, designers have the opportunity to help build the vision of the product. We just have to step up. The whole point of building a design culture is to make the experience of the user a priority. That means designers have to push to be a part of strategy. This doesn’t come naturally for everyone. In the past, this was a conversation between product owners and developers. To add designers to the conversation, this involves creating the expectation of roadmapping and planning together. This means to be clear on what the clear goal for the user experience should be. Then align the technical and design requirements with business needs.
