The Hidden Challenges of Design and Agile: Vocabulary
Lean UX, Design Sprints, Mobius Loop — all of these frameworks are bringing revolutionary change within the agile community by integrating pieces of design into day-to-day agile practices. As these frameworks increase in number, we pause to reflect. What is the problem we’re trying to solve? Agile has cadenced processes whose pace ends up constraining the creativity of design. Design is more than pixel pushing, however, its true breadth can be hard to grasp for non-designers. Trying to combine a cadenced process with the breadth of ideation can seem like we’re trying to mix water and oil.
Even when sticking to best practices, when striving to integrate design in agile teams, things can take unexpected directions. Designers point out rightfully that arbitrary sprint deadlines force teams to take less risks. Scrum masters try to manage multiple backlogs to satisfy both engineering and design needs and the team ends up siloed. It is too much for one individual to handle changing “the process” or “the organization” — so they either unhappily bear with it, change their mind or quit the company. It is more common than ever for designers, developers, scrum masters and product managers to surface issues in design sharing their work too late or a general lack of curiosity in their team. What’s going wrong?
To enact large-scale change across teams and the organization, it’s easier to break down what isn’t working so that you can focus on the problem piece by piece. We understand that everything is interconnected, but seeing everything at once can be overwhelming. Frameworks oftentimes give the solution before attempting to understand the problem.
We wrote this to help you make sense of this mess.
Based in the bustling city of Tokyo, Japan, Chelsea is UX Lead at yamaneco, an agile-first company. Davide is Tech Lead at AQ, a design-driven studio. We’re passionate about fostering collaborative teams of designers and developers and enacting change at organizational level. We know change takes time, but we have experienced many successful cases, with both willing and unwilling clients. If you’re interested in understanding and rising to the challenge of making your own change in your organization, read on.
Uncovering the hidden challenges
We went beyond scratching the surface of these real issues and identified three common hidden challenges. These challenges come from our personal experience of being practitioners and coaches in both design and agile teams.
The first is the challenge of vocabulary. Both design and agile have grown similar but very different vocabularies, which makes communication fraught with misunderstandings.
The next is the challenge of context. Something that worked in one environment won’t always work in a new one, so what happens when we introduce two different methodologies like design and agile?
The last is a challenge of outcomes. The team is too preoccupied with releasing features and the organization, too focused on impact to realize the value of investment in design mindset.
They are often not spoken about, or when brought up, are deemed “too big” or “too high risk” to pursue. The low-hanging fruits get in the way of pursuing monumental change. We’ve written this so that you can confidently and clearly speak up about these challenges.
In this article, we’ll tackle the challenge of vocabulary and follow up with the more complicated topics of context and outcomes.
Defining agile and design
As we are to first address vocabulary, let us ask you — are you on the same page with your teammates on what design and agile mean? Your organization? You may already be familiar with the terms, but in the context of this article you may find that we define them slightly differently.
Agile in this article refers to an approach to software development that, in contrast to traditional assembly line flows, advocates for cross-functional teams developing iteratively small batches of work.
What agile is not is any specific framework, like Scrum or Kanban, a daily stand-up, or developing software at speed. This is an important distinction to make when speaking about agile, especially because typically what people experience as agile (sprint reviews, backlog refinement) are activities that are part of an overall approach.
Design mindset is a way of thinking about product creation that is curious, iterative and human-centric, helping teams create creative and useful solutions that solve the problems they were meant to solve.
A design mindset is not the same as wireframing or prototyping or frameworks like Lean UX. What people experience as design (prototypes, screens) are valuable because they contain the designer’s thinking within them. They are valuable because they provoke discussion and a deeper understanding of both the problem and the solution.
We will be referencing both of these terms throughout the article, and defining these terms is especially relevant given one of the biggest challenges in integrating the two are the words that are used while integrating them.
What you say matters: the challenge of vocabulary
At a high level, the agile workflow and design mindset have many similarities. Taken from Matt-Cooper Wright’s article on Blurring the Lines between Agile and Design:
Both processes seek input from beyond the team doing the work…both processes also embrace iteration and ongoing refinement. Less obvious, but equally important, is the strong call for a healthy culture of empathy and empowerment in the team.
Both agile and design call for feedback, iteration and empathy. So why can’t they agree on a set of activities and behaviours to fulfill those? This is because they sometimes don’t speak the same language.
Chelsea has written an entire article on the phrase “Is the design done?” and how it can be misunderstood. In short — the idea that we all know and agree upon various meanings of the same words is false.
Take the word prototype, for instance.
When speaking with one of her clients here in Japan, Chelsea recalls them requesting a prototype to show to stakeholders. In this case, the word prototype was unclear — they wanted something to help them visualize the application but they also wanted something they could present to stakeholders. What did they want, exactly?
For designers a prototype could be a simple pencil or whiteboard sketch — in the dev world any form of prototyping — as basic as a spike — is a somehow working piece of software.
In this case, what they wanted wasn’t a prototype at all. When questioned about what their specific needs, they mentioned that the stakeholders requested a well-thought out navigation and content sections. Chelsea suggested they first consider a sitemap to improve their understanding of the application’s architecture before a prototype. She provided an example of what a sitemap looked like, and they agreed. In this case, she delivered something that the client didn’t ask for — but it was something they needed. However, she only knew this because she sought to question what purpose the prototype was serving. Were her clients to ask someone with a more set definition of “prototype,” they would get what they asked for, but not what they really needed — a well-structured navigation.
Or Design Sprint, a multi-day workshop-style activity to ideate and validate new products, services or features. Unless you already clearly understand the above definition, “Design Sprint” is a term that throws off almost every person involved. For developers, the word “design” means “doing UX and UI” and this is something that not every developer is interested in. For designers, the word “sprints” mean an agile-focused mindset, and as such, is more conducive towards production than iteration. For business people, it’s confusing. “Fantastic, so we’re going to run a development sprint and a design sprint at the same time, right?” is what we hear when the word design sprints is brought up.
The information architect Abby Covert in her book “How to Make Sense of Any Mess” introduces the idea of a “controlled vocabulary” to facilitate shared understanding between the user of a system and the designer.
“A controlled vocabulary is an organized list of terms, phrases, and concepts intended to help someone navigate a specific context.
Documenting language standards can reduce linguistic insecurity.”
We would argue that linguistic insecurity not only happens between the designer and the user, but within teams as well. Linguistic insecurity can lead to larger issues such as in-group fighting and distrust. Be mindful of how much jargon you use. Jargon is direct and to the point (and yes, it’s cool!), at the price of being mysterious and unintelligible for people with limited experience on the topic. Davide realized that onboarding of agile first-timers was smoother when using the words iterations, team-sync and estimation instead of sprint, daily Scrum and planning poker.
If we can’t communicate, why communicate at all?
There will never be a perfect understanding of a word between two people, however well they know each other. Instead of focusing on perfecting this definition, simply accept this. Work out a glossary. Invent words if necessary. This is how new languages are born. Onboard new employees to the glossary.
Two great examples of this are Spotify and Basecamp. Each company has decided on a new language for their team, one that doesn’t represent prior notions but something different and coined by the team itself. It creates ownership and a more shared understanding if the team is defining these words for themselves.
Spotify renamed their agile teams “squad” — along with a plethora of other terms — effectively removing all words that connected with any pre-existing concept or framework. The benefit is that, as we tend to attach emotions or previous experience to words, using neutral ones challenge the team to define themselves. As a new member or Spotify, the word “squad” invites curiosity. How does a squad behave? How do squadmates collaborate? Joining a traditionally named Scrum team encourages more of a bias on what to expect, and can have an unexpected downside of only attracting members who feel positive about the idea of working in a “Scrum team.”
Basecamp’s idea of “appetite” sparks conversation as the word is typically used in regards to hunger, not planning. If you “don’t have appetite” for something it begs the question “why?” because there are a variety of reasons — you’re sick, there’s too much food, etc. Similarly, while planning, you should know why something is not being done. If you plan everything based on how many hours a team can contribute to a feature (i.e. points), you’ll miss questions like “does the user want to use this?”, “do we have the analytics to test this feature?” and most importantly, “is this something the team actually wants to work on?” Ignore these, and you’re bound to make a constantly-shifting roadmap that not everyone is aligned on.
In addition to controlling your vocabulary and inventing new terms that spark curiosity and conversation rather than a presumed understanding, we’ll also cover some commonly misunderstood words you may want to consider defining.
How to identify a vocabulary challenge
Sometimes it’s hard to identify a vocabulary challenge until after a misunderstanding has occurred. Take note of what common words are easily misunderstood — did design present something to the dev team that was then dismissed as, “we can’t use this”? Did you notice that the team is particularly allergic to a word or a concept? Dive deeper into it and question what the needs are from the team and if the concept as you’ve defined it is meeting those needs.
Here is a short list of commonly misunderstood words in agile and design teams:
The key is balance. We don’t want to spend too much time arguing over semantics that don’t matter, but we also don’t want to pretend like these vocabulary issues don’t exist.
Download this worksheet and take some time to have a conversation with your team about the words above that they use and what are the new words they may be able to use to create new context within your team. Post it up in a place where you can see and refer to it.
Having a good conversation starts first with a good definition of vocabulary. Just as language changes over time, so will the definitions of these words, so don’t worry if your document doesn’t capture everything. The important part is that it will eventually be used for aligning the team and onboarding new teammates. Next time you see small disagreements between development and design to large-scale arguments between leadership pay close attention — what words are they using? Do they mean the same thing?
Some questions to consider asking…
- What was your prior experience with (word)? Give me an example of what you expect.
- If (word) has little value, what would you use in place of it?
- What do you need to accomplish? How will (word) contribute to this?
These can help clarify meaning and get to the point. Understanding that you both mean the same thing is key to establishing some mutual connection and trust even if you don’t agree with your teammates’ point of view.
That’s it for today. We hope that you find these useful in identifying the types of challenges you’re facing and how to articulate them when you find them. In the second part of this three-part series, we’ll be covering the hidden challenge of context.
In the meantime, we would love to hear your feedback and know what challenges you are facing.
What words throw your team off? What are your hidden challenges?