The Product Designer’s Guide to Agile
Learn everything that a Product Designer needs to know to thrive on an Agile team.
Reading Time: 10 minutes
What do seventeen developers trekking up a mountain in 2001 have to do with your design job? Everything.
Agile is the most dominant methodology in software design, and it’s not going anywhere. But many designers don’t feel empowered by it. That’s because most teams go through the motions of Agile without the spirit.
If you get Agile's original intention, you can thrive in any flavor of Agile.
What is the definition of Agile?
Here’s how to define Agile:
Agile is a way to build software that releases updates regularly and learns iteratively from the customer's real-world reactions.
To quote the strategically-chosen words of its founders, Agile is all about:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
What does Agile mean?
Agile means different things to different people.
While almost every company claims to be working in Agile, not everyone agrees on what that means. I'll try to summarize the general meanings that I have come across in my career:
Agile to a Developer = We release updates to the codebase every sprint
Agile to a Product Person = We follow sprint rituals and break our work down into small tasks
Agile to a Designer = We respond to customer’s needs quickly
Agile to a CEO = We build a lot of features quickly
As each team member claims a different interpretation of Agile, they dilute the methodology. How do you practice Agile properly? Let's start at the beginning to get a better idea of Agile.
The History of Agile vs. Waterfall
It was 2001, and developers were sick of the way corporations made software. They were tired of the heavyweight, bureaucratic process that made most software companies look like a Dilbert cartoon.
In the 1900s, the dominant approach for building software was the Waterfall Method. Waterfall is an innovation of industrial design and is comparable to an Assembly Line. This model separates work into sequential phases of specialized labor and requires a central controller or planner. This approach favored documentation and planning since it required complex handovers between the different stages in a project.
In 2001, the organization of engineering work still looked a lot like the organization around building a physical product. It was the right time to establish an alternative for building software products. So they got 17 representatives from all the latest software methodologies (including the still popular SCRUM) together and made a new methodology called "The Agile Alliance."
These were organizational anarchists.
They decided on a list of principles that would guide software development in the direction they desired. They called it The Agile Manifesto, and you might be surprised how much human-centered language is in it. Here are a few principles designers might be interested in:
Principle #1:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Principle #9:
“Continuous attention to technical excellence and good design enhances agility.”
Does this sound like a methodology at odds with the user experience? Agile is a system designed to release tangible improvements to the user experience every sprint.
I've had many ideas for improvement shot down by developers in the name of Agile in my career, which is a good thing. Agile forced us to prioritize the release of something tangible for learning. It helped us negotiate and make decisions.
How Agile Benefits Design
Agile doesn’t just benefit developers. Designers using Agile can get benefits, too.
Realistic scope of work in manageable chunks
Real-world data from weekly launches
More collaboration with developers
Responding to customer change improves UX
Product-focused rather than project-focused work
Actual, working product instead of unrealistic plans
1. Agile is about empowering teams.
The radical part about Agile is that the team controls “how” the work gets done—most of the problems with Agile stem from a lack of empowerment to the groups using it.
Principle #11
"The best architectures, requirements, and designs emerge from self-organizing teams."
People shouldn't be "resources" in Agile. Agile requires trust so that teams can make decisions, not managers. Teams are only truly Agile when they are empowered to decide how they will work. As they work and release, they learn about the customer continuously. Teams ultimately build better decision-making instincts than executives, and Agile puts teams in a position to use this expertise daily.
Agile provides a rare win-win in software companies. It makes better-performing teams, and it allows teams to manage themselves. Agile reduces cost and bureaucracy while increasing quality. Understandably, many teams want that, but most companies prefer to order work from the top rather than empower individuals from the bottom.
2. Agile requires trust in individual contributors.
Principle #5
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Building customer expertise takes time, but many companies aren’t always willing to wait while teams develop the decision-making abilities that customer expertise provides. Sometimes, the engineers will need to sit in on customer interviews. Sometimes designers will need to test things before they’re built. Seeing workers do unexpected tasks or sit idle (especially expensive engineers) can make management very nervous.
Clients and managers may decide that they like the delivery side of Agile but don't feel comfortable letting the team decide how to build something. When tasks are assigned and required, team members lose the ability to react to change. Without empowerment, Agile turns into a hollow methodology. In this dis-empowered Agile setup, work becomes a prison of weekly deadlines.
3. Agile is anti-bureaucracy.
When the teams don't control what they build, bureaucracy becomes the predominant form of control. Product roadmaps and overly detailed sprint requirements force teams to focus entirely on Delivery rather than iterative improvement. When you force teams to deliver complicated plans, you end up with the Project Mindset of Waterfall, not the Product Mindset of Agile.
The Project Mindset approach to Agile is known as "Agile Theatre" or "Agile for Delivery," and it's the reason that many designers feel that UX is incompatible with Agile. The misunderstanding stems from the misapplication of Agile, not the methodology itself. Ironically, the bureaucracy surrounding Agile is precisely the kind of bureaucracy that triggered the inception of Agile in 2001.
Single-Track vs. Dual-Track Agile
Since 2001, Agile has evolved to enable more discovery and accommodate different organizations. There are two main models of organizing design and agile.
Single-Track Agile
Single-Track Agile is the classic approach where everyone on the team simultaneously works on research, experiments, design, and development. That means developers help with the design, and product managers discover alongside the designers.
Scrum is a popular Single-Track framework for practicing the values and methodology of Agile. Two of the seventeen Agile founders also co-founded Scrum. Scrum is where you get the rituals like daily standups and retros that most Agile teams use.
Single-Track Agile might seem wasteful to the outside observer, but the expertise built by the team members pays off in the long run. Teams that work this way build customer expertise and strong team bonds, a winning formula to make the best software on earth.
Single-Track Agile is the most effective model for in-house software teams that work in an uncertain business environment with challenging goals.
Dual-Track Agile
One of the biggest critiques of Agile is that it focuses too much on Delivery. It isn't easy to do user research when the developers are constantly bugging you for the final design so they can code the next release.
You can fix Single-Track Agile's focus on Delivery with a separate track to focus on Discovery. Marty Cagan popularized Dual-Track Agile with his book, Inspired in 2012. Marty made the case that discovery work (build the right product) should work in the same agile approach as the delivery work (build the product right).
Designers might recognize the Double Diamond in this separation of work into Discovery and Delivery. I've even seen a product article that uses the Double Diamond to represent Product Discovery.
Dual-Track is similar to single-track except Discovery and Delivery tasks are carried out in parallel. The two tracks should have the same goal, and they should happen at the same time.
Dual-Track works in teams with lots of UX and research capabilities or teams that prefer to let the engineers focus on Delivery. Dual tracks can cause information silos and specializations as developers miss the learning loop. You should share the same product backlog and get designers and engineers to meet daily to combat this.
Split-Track Agile
Beware Split-Track Agile, where the Discovery Track determines the backlog of the Delivery Track by keeping design one sprint ahead of engineering. Split-Track quickly becomes a "Mini Waterfall" approach and should be avoided.
If you require a lot of Discovery and keep developers busy, this method can provide an alternative to Single-Track Agile.
It’s hard to integrate UX design and research with Agile, but I hope you better understand how integration is possible. Agile is one of the most important innovations in building software. If you spend time learning to thrive in Agile, it will be well spent.
Learn More About Agile
Read 5 Ways to Make UX Research Agile by Pete Armitage
Read What is Continuous UX Research? by Jeff Humble
Read more about Discovery vs. Design by Marty Cagan
Read Dual Track Development is not Duel Track by Jeff Patton
Watch Lean, Agile, & Design Thinking by Jeff Gothelf
