Day 37 — Process series 6/7: “Agile + UX”
How do we know if we’re true Agile? What makes of a good UX focused approach? And when we want to combine the power of two worlds, how do we make sure it’s successful?
It only makes sense to talk about how Agile & UX can co-mingle together, given the title of this blog, “Daily Agile UX”. Hence this post is going to address 3 things:
- What are the key index of successful Agile UX
- How to form a Agile UX process
- What are the tips, tricks to adopt, pitfalls to avoid
Just a couple short stories
1. Why Agile
The term “Agile” in software development was coined by a group of brilliant developers. Back then (around dot com bubble), there was a short supply of designers in enterprise software development industry. The concept of Design Thinking hasn’t gone popular yet, therefore those few designers worked on enterprise software rarely knew or performed Design Thinking in their process. As a result, enterprise software with inappropriately-implemented Waterfall process created either “analysis paralysis”, or “product never see the sunlight”, or “solving the wrong problem”. These talented and passionate developers tried to solve this problem with their developer mindset, and proposed that since analysis could be blockers rather than enhancers in terms of finding the right product-market-user fit, let’s just release product fast and test the water often, so that it shorten the trial-and-error cycle, for the purpose of saving effort and investment.
2. Why UX
Before the 1st iPhone was launched in 2007, most of the product companies were competing in the product market with higher technical specification, as the major aspect of value of products. The thought was if the product with better camera lens, or stronger CPU, the product is more valuable to users therefore sales and revenue would go up. And Steve Jobs proved people wrong. Customers want good product experience instead of powerful but annoyingly hard-to-use products. Time travel back to 1993, Don Norman joined Apple and asked for his job title to be User Experience Architect, which contributes to Apple’s success story. As a result, these events forever changed the product industry, and the way people view design, learned that design is more than “putting lipstick on a pig”.
3. Why these two stories matter
If I may use an analogy to describe how these two concepts help improving product quality or business success, this is how I’d describe: Back in the days in the enterprise software development world, developers were asked to (figuratively) shoot a target 200 feet away, but they were given a rifle with a broken scope (wrongfully done product analysis). However long they tried to adjust the broken scope, they just couldn’t see nor aim the target right. As a result, the bullets kept missing the target.
Instead of fixing the broken scope, they decided to ditch the rifle and the broken scope, and swap with a machine gun that shoots fast. By keeping shooting bullets fast and frequent, one of the bullets will eventually hit the target. Then developers can analyze how that bullet magically hit the target, and learn from it to evolve the way they shoot.
While that machine gun method improves the process, UX designers takes a different way to solve the problem. They know that the real problem wasn’t the rifle, it was the broken scope. So instead of throwing away that rifle (Waterfall process), they try to fix the scope (by adopting User Centered Design approach, rather than relying on traditional business analysis). After fixing the scope, they can see the target more clearly, and watching for other influences that might impact the aiming (e.g. seeing where obstacles are, calculating wind speed, etc.) As a result, designers improved the accuracy, and hit the target faster with less bullets (investment) and limited trial-and-error.
That being said, does it make one method superior than the other? Not exactly. They both have their merits, and a wise product team knows when to choose what method. As the figure below indicates, Design Thinking helps explore the problem space, and redefine the problem to be more accurately. Agile, on the other hand, helps validate if the solution performs as expected, or it requires pivot. In between Design Thinking and Agile, there are other methodologies like Lean UX and Google Design Sprint to help fill the gap.
Success Criteria for Agile UX
If Agile and UX can co-exist, what is the success criteria of [Agile UX]? When we look at the essence of the two methodologies, both emphasize learning and iterating. Since software is never finished, a successful project that adopts Agile UX should consist of the qualities below:
- Emphasis of learning
- Open culture of different ideas & methods
- Encouraging “failing then getting back up quickly”
- Flexibility between organic and structural process
These qualities are the make-or-break criteria for companies going though digital transformation and competing in the arena of emerging technologies. How so? Without the psychological safe zone, team members wouldn’t want to contribute (or commit to) new ideas; without the established process of learning, all the endeavors become an one-off experiment, buried six feet under and nobody knows; without flexibility between organic or structural process, teams could form unnecessarily conflicting positions, and it damages team morale and productivity.
Form an effective Agile UX process
A simple 3 step process could serve as principle solution of forming Agile UX team:
1. Over communicate a clear vision and guiding principles
In yet-to-transform companies, we’ve often seen the mission and vision statement stay between C-suite and senior management. The “Change-the-Shop” mindset didn’t infect the teams who are actually doing the work, as they are still staying in the “Run-the-Shop” mindset to secure the jobs and paychecks. It’s imperative to over communicate the vision and guiding principles to make sure everyone’s on the same page and know clearly where we are heading.
2. Establish fun & formal routine learning rituals
In order to truly and effectively adopt Agile UX, the learning ritual is absolutely necessary. Once the effective learning rituals (e.g. sprint retrospective, war room, guerilla user research, etc.) become a habit of all team members, great things happen. Team members feel like their growing their capabilities by learning new things, they become more confident, their commitment becomes stronger, and therefore the product quality enhances.
“Data gives us certainty, creativity gives us possibility” — Stephen Gates
3. Embrace both data and creativity
Some of us might still remember management thinker Peter Drucker’s famous quote: “you can’t manage what you can’t measure.” Having a vision is great, but it’s equally important to create a method to measure the progress toward the vision. More importantly, as time goes by and market and other condition changes, we also want to measure if the vision is still relevant and inspiring. Design leader Stephen Gates once said, “Data gives us certainty, creativity gives us possibility”. Utilizing data helps you know where you are toward the goal, and embracing creativity helps you create better or faster way to get to your desired destination.
Challenges, and Tips & Tricks
1. Confusion, Misunderstanding, and Conflict
Since Agile principles were created by developers and largely adopted by software developers, the emphasis not so much around UX & design. Vice versa, Design Thinking is popularized by designers and didn’t address much around the challenges in software development. We’ve seen the compliant from both sides because of lack of understanding of the others. It’s not uncommon in human history to have dichotomy, Windows vs. Mac, Android vs. iPhone, etc. It’s important to understand that both have its merit, different tools/methods are better on different task or in different context.
Solution: Build empathy by merging teams and pairing their workflow. Most of the time, confusion and misunderstanding come from lack of communications. By merging team and their workflow help teams build empathy, learning how others see things, make decisions, and resolve challenges.
2. Team member can’t pull it off
As we probably all learned that, “a tool is as good as its user.” Agile Manifesto emphasizes “individuals and interactions over processes and tools”. However, if the individuals in the team have limited interest in building quality product, but more desire around “getting paycheck on time and getting home early”, it could be challenging to build a self-learning team with Agile experiments. Similar situation happens in adopting Design Thinking. It’s a design model that describes the general flow that consists of various types of User Centered Design (UCD) activities. If design team members are not experienced or not interested in conducting/ facilitating these UCD exercise, blindly forcing these collaborative work onto either design team or users/stakeholders only do more damage than good.
Solution: Wisely select methodologies depending on team member’s competency and working style. Not everyone is “in it to win it”, some just want to fly-under-the-radar. As a product/design leader, the most important thing is to find out what management methods suit different team member’s style (as figure below). By gauging the competencies and proactive-ness of individuals, we can decide whether we want to go with more structural methodologies (e.g. Waterfall, Scrum), or more collaborative/generative ones (e.g. Lean UX, Kanban)
3. Lack of support during the implementation
As Mike Tyson famous quote: “Everyone has a plan until they get punched in the mouth .” Without proper support from stakeholders, any plan or chosen methodology can go wrong easily. Project success are often contingent to time line, resource (budget to implement, headcount, etc.), and stakeholder’s expectations.
Another scenario is, when the process doesn’t go as well. “When tough times come, you know who your true friends really are.” When there’s less progress made as expected, performance didn’t reach the goal, people start questioning if we chose the right way to do things.
Solution: Believe in the process and advocate for it internally and externally. Leverage success case studies to be more convincing. Also, accumulate small wins during the process to gain stakeholders’ confidence in us, and our chosen way to do things. In other words, bank the success along the journey in case there’s a rainy day.
Conclusion
- Agile & UX are different means toward the same goal. Given the overlapping nature, they can co-exist if used wisely.
- The journey of pursuing either Agile, or UX, or both, requires the right culture and the right people. They’re highly effective if you have a highly effective team with proper project support.
- Most of the problem are people problem. Clear communication, empathy toward each other, and a shared goal is the way to bring people together and prosper.
Do you have any experience adopting UX in an Agile environment? I’d like to learn from your experience!
ABC. Always be clappin’.
