As Agile has become the standard working model for development teams, UXers are, oftentimes grudgingly, learning to integrate into existing Agile development teams. But few are exploring how a UX team can use Agile techniques, and perhaps more importantly an Agile mindset, to improve team performance and morale. It turns out that when done right, Agile can help UXers achieve personal and strategic goals, giving value and purpose to the problems UX teams face daily.
Sound too good to be true? If so, read on to learn how this cross-functional UX and architecture team used an Agile approach to improve our product, team performance, team member engagement, job satisfaction, and influence.
But I Don’t Like Agile!
You might have heard from others that Agile is boring daily status meetings and relentlessly short deadlines that make it impossible to deliver anything of value. You might have heard that Agile does not allow time for UX work. You might have even worked with so-called Agile teams where the user experience was downplayed or you were asked to compromise your values. No wonder you don’t like Agile!
What Is Agile, Really?
Our experience with Agile proved to us that these statements and experiences couldn’t be further from the truth. Agile is an approach to doing work—any work, but especially complex work—that emphasizes transparency, trust, honesty, and collaboration. It places a strong emphasis on delighting, and interacting with, our users. And while Agile does encourage short feedback loops, it definitely does not ask us to compromise quality in order to achieve them. Those short feedback loops are intended to help us get quick insights from our users so that we can continue to iterate until we meet or exceed their expectations.
Our Experience
Our team, three UXers, two architects, a manager, and an Agile coach, was designed to support the vision of the director of software development. He wanted to build and roll out a method for product development across the organization that was responsive to user needs, produced business results quicker and more effectively, and encouraged inclusion of colleagues from all areas of the development and product organizations. Because our team performs change management work and is necessary to the product development process, his approach was for us to work together on the initiative, rather than separately.
Except for the Agile coach, we had limited experience with Agile, but our manager had used this approach with different types of teams in the past and helped us see the opportunities. Being a servant leader, his approach was to expose us to the ideas, give us access to a coach, and then let us work together to figure out what would work best for us.
Our manager explained it this way:
“It was always our vision to bring together the true customer-first mentality of user experience experts with the technical forward-thinking of architects. We felt we could genuinely create collaboration between these two roles by utilizing Agile principles and that the results would yield an industry-leading experience for our customers.”
—Mike F, manager
We were not completely convinced but were willing to give it a try. Accordingly, we approached our Agile initiative as an experiment, forming a hypothesis and trying different things until we found something that worked.
Where Do I Start?
Our first step was to get off site for a day where we could be free of the distractions in the office. This approach really helped us open our minds to new and different ideas. We started the outing with a team retrospective, a meeting to discuss what was working, what wasn’t working, and to decide on next steps.
We covered the wall with sticky notes, calling out our pain points (see Figure 1). After some discussion, we managed to group them into three main areas:
- The UX and architecture teams were not being included early in the product development process. This was leading to last-minute changes and a lack of attention to design and technical standards.
- Our manager was being pulled in many directions, making it difficult for him to help team members grow as influential contributors within the organization.
- We were placing little, if any, emphasis on developing our individual skills and collaborating with our colleagues within the organization.
Figure 1: Our Agile coach helped the team work through priorities during our offsite retrospective activity.
After the retrospective, our Agile coach facilitated an Agile team self-assessment so that we could identify our current Agile fluency level. Not surprisingly, we scored ourselves as having little to no fluency with Agile, and struggled to understand how we might apply the techniques to our work.
We continued our discussion and chose a few Agile techniques that we thought might help us alleviate some of our pain points. Our Agile coach helped us understand which techniques might be good fits and why.
We decided to try out the techniques outlined in the following sections.
Team Name
Deciding on a name for your team might seem trivial, but it’s an especially effective way of helping teams start to see themselves as a single entity working together toward a common goal. We found that it was quite hard to find a team name that we all liked and that adequately captured our team’s personality, purpose, and situation within the greater company’s culture.
One day at a team lunch, one of our members threw out that we were like the “Misfit Toys” from the Rudolph the Red-Nosed Reindeer Christmas special. It fit because of our collection of skills, our placement “on an island” outside of the product development process, and our empathy and caring for users and our colleagues.
Physical Team Board
Figure 2: Our physical team board helped us engage in more meaningful conversations and helped us get our work done faster.
We were already using an electronic tool to manage our work but wanted to find a way to make all of our work more visible to our team members and ourselves. We were also trying to find a way to encourage richer conversation between team members and create transparency to the organization about the work we were doing. We started doing our daily stand-up meetings (see next section) at our physical board and noticed that they became more meaningful. We were getting work done more quickly and finding ways to help each other.
Daily Stand-Up Meetings
Figure 3. The team met at the physical board every morning for stand-ups up that helped us work better as a team.
Daily stand-up meetings are a common Agile practice that comes from the Scrum framework. The concept is that the team meets briefly once a day, typically in the morning, so that each team member can share what they’re working on that day and what, if anything, is blocking their work. The stand-up helped us get to completion faster, better understand each other’s work and blockers, and function more like a team solving problems together as opposed to individuals working in isolation.
Sprints (aka Iterations)
The concept of a sprint also comes from Scrum. A sprint is a timebox of one month or less (the shorter the better) in which work is “pulled in” by the team and completed. In development teams, completed or “done” often means working in production. For us, “done” meant we could demonstrate the work and it could be released to the greater organization. We found that using such a timebox helped us focus on the most valuable work and provided a tool to enhance our discipline around getting one thing done before starting another.
As a team with not enough people and more work than we could possibly do, one week-long sprint helped us get out of the overwhelmed frame of mind and into one where we could get things done and have a sense of accomplishment. It also provided a tool for communicating with stakeholders about what we were doing and when they could expect our assistance.
The struggle with short timeboxes was that our team was unused to working on one small thing at a time. For us, the trick was to figure out how to break down large assignments—like user research—and design into several smaller, bite-sized chunks of work that could be completed one at a time in just a few days.
In the user research and design example, we might break the work down into chunks like this:
- Interview users of one specific type and file the resulting data
- Create a quick sketch based on the resulting data
- Schedule a meeting to review resulting data with product and development and get feedback
- Update sketches based on feedback from product and development
- Create a recommendations document
- Continue to test and design for another specific type of user
While choosing such a small sprint cadence might seem crazy, it was actually very useful. We found that with a shorter sprint cycle we could be more responsive to our partners on the development and product teams. The developers were working in three-week sprints and because we were not embedded in their teams, it had been hard for us to provide the support they needed in their sprint cadence. By choosing a shorter sprint cadence, we were able to easily pull in the work we needed to do for them with little notice and complete it before their sprint ended.
Retrospectives
Figure 4. One of our retrospectives resulted in a short list of things to try in the upcoming month: (1) Push to next month instead of “right now” (2) keep the [physical] board (3) delegate to team members (4) office hours (5) use the scrum master
Scrum Master
The scrum master is a member of the team who is primarily responsible for supporting the team’s Agile growth and removing blockers and distractions. The scrum master is a servant leader who leads through influence rather than authority. In practice, the scrum master often leads Agile ceremonies and coaches team members on Agile techniques.
We were not able to gain approval for a full-time scrum master, so we rotated some of the responsibilities between us and assigned others to our manager and Agile coach. We took turns being what we called the “Sprint Leader,” facilitating daily stand-ups, retrospectives, and other team ceremonies, while our manager handled coaching the product representatives, and our Agile coach helped us grow our Agile skills and mindset.
This approach helped us share the burden for a role that we felt was crucial to our success when we could not fill the position with one person. By rotating the responsibilities among the team members, we also better appreciated the role of the scrum master and had the opportunity to build our individual leadership skills, regardless of our official titles or roles in the team.
One Year In
About 12 months after our Agile journey began, we took some time to reflect on where we had been and where to go next. It turned out that our hypothesis was true. Agile did help us better manage complex work that required collaboration across disciplines. Despite struggling with the concepts at first, we were able to adapt development practices and techniques to our work and our craft, greatly improving our productivity and satisfaction with our work.
As part of this exercise in reflection, we completed the Agile team self-assessment again and learned that we had improved from “Little to None”-level fluency in Agile to Working knowledge-level fluency (see Figure 5).
Figure 5: Our Agile fluency improved from Little to None at the start of our experiment to Working knowledge by the end of the first year.
We now better understood the themes and practices applied in an Agile team and could see how they applied to UX. Perhaps, most importantly, we realized that we were enjoying our work more, felt like we were contributing to improving the product, and our work was valuable to both our users and our company.
One of our UXers had this to say about her experience:
“One of the best things about Agile and UX is that you learn how to be an efficient UXer. I really do believe that UX and Agile work great together. I am learning to support my decisions with the right amount of research and work with developers closer than before. It taught me what cross-functional collaboration is and made me feel comfortable to ask questions. I am learning more about expert users while being productive. It all starts with an assumption and then validation.”
—Catalina M, UXer
It was enlightening to recognize that almost without realizing it, we had started to feel more like a cohesive group. We were supporting each other more, and we were all moving in the same direction toward the same goal. We had also begun to add significant value to both the organization and the product. Perhaps even more impressive, other teams and groups had started to recognize the value we brought to the product development process and began to ask for our help and to engage us in the product ideation and planning processes.
One team member, an architect, put it this way:
“Prior to transforming to Agile, work would always be flowing in, without any sense of prioritization or focus, and [that] led to a lot of context switching and churn amongst team members. Shifting to a more Agile thought and work process allowed the team to remain focused on top company priorities, provided visibility to the team on a daily basis on what was accomplished and being worked on, and provided an improved sense of accomplishment at the end of every sprint.”
—Scott M, architect
Current Day
Today, the team continues to work in an Agile fashion. Even after the departure of our manager, our biggest Agile enthusiast, we still use the same mindset and techniques to manage our work. We have found them too valuable to give up. In fact, we have continued to adapt our way of working and have adopted even more Agile techniques, among them:
- Including a narrative for each story, or small chunk of work
- Added acceptance criteria to stories
- Reformulated weekly team meeting to include Sprint Planning, Three Amigos/Post Huddles, and Sprint Review
- Started to be more deliberate about prioritization, playing related UX, Agile, and architecture stories in the same sprint.
Intrigued?
Hopefully we’ve persuaded you to consider an experiment with Agile. If so, here is some advice, from one UX team to another:
- Do not rush into anything. Schedule an offsite to define what’s working, what’s not working, and to decide on next steps
- Look at your working space. A team that sits together communicates efficiently and effectively. If you’re feeling brave, consider experimenting with an open-concept seating arrangement.
- Identify next steps and techniques you may want to try. Stand-ups and retrospectives are easy to implement and typically result in big wins.
- Chat about roles and responsibilities. Who is the scrum master? Who will write the stories? HOW MANY STAND-UPS DO I NEED TO GO TO?
- Communicate regularly. Plan to talk about what’s working, what’s not working, and to decide on next steps at regular intervals.
- Rinse and repeat.
It turns out that an Agile mindset not only works with UX, but it also supports the user advocacy efforts of the UX team. Additionally, even with strong personalities and lots of differences, a strong Agile team can emerge because every day the team grows and learns what is needed to be supportive and caring. By encouraging a user-centric focus to the development process and supporting collaboration among diverse functional groups, Agile helps us move toward a product that delights our users and a work experience that we can all feel good about.
Suggested Reading
For more information on the ideas introduced in this article, we suggest the following books and reading materials:
- “Manifesto for Agile Software Development”
- “Principles Behind the Agile Manifesto”
- Lean UX by Jeff Gothelf
- The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson
- Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days by Jake Knapp and John Zeratsky
Retrieved from https://oldmagazine.uxpa.org/agile-ux/
Comments are closed.
