Wait, what? How can you claim to take an Agile approach to design if you’re still defending the dreaded Waterfall process? Working Agile means preaching the gospel of sprints, stand-ups, and backlogs. Right? Once a month we throw a Gantt chart into a volcano to prove our unwavering loyalty to the Agile gods. Right?
No… not right. Agile isn’t a list of laws, it’s a set of values. The original Agile manifesto was created by a group of self-proclaimed “organizational anarchists” that never suggested their ideas should be applied forcibly. They wanted to help software teams think differently.
That’s exactly why sometimes we need to consider suspending some of the processes that we affiliate with Agile in the name of the principles that define Agile.
If creating software were a game, Agile’s 12 guiding principles would be the coach’s soaring pep talk that rallies the team to victory.
Here are the guiding values of the manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Acknowledging there is value to the items on the right, the Agile philosophy prioritizes those on the left in bold. I’m a huge believer.
Why I Believe in Agile
The manifesto was written for engineers, but for designers the benefits of working Agile are incredible. Here are just a few of the reasons we at Nonfiction love it:
- It’s all about the end results, and so are we.
- It helps us develop a better understanding of the problem and purpose.
- It helps us to establish a flexible vision that constantly gets better and clearer.
- It allows us to take risks, test, and adopt or discard ideas more easily.
- It facilitates candid communication between us and our clients.
Agile gives us a shared cultural philosophy to rally around.
Why We Sometimes Break the “Rules”
You see, for all of its unstructured goodness, Agile has become synonymous with the frameworks that it inspired. You’ve likely heard of the frameworks Scrum and Kanban at least by name. They apply the Agile values in similar, but distinct manners. Before you get caught up in the jargon, I want to direct you back to the Agile manifesto bullets I started with above. In particular this one:
Individuals and interactions over processes and tools
The minute we begin to prioritize the rules of a framework over individuals and interactions we’ve betrayed these basic principles of Agile.
Software isn’t made by product people alone
For every designer, there will be aspects of our job where an Agile approach makes work 100X easier. But product development is only one of many areas of a software business. For groups like finance, HR, marketing, or sales, there are other timetables and linear flows that matter very much to their ability to work. An attempt to force them into an Agile framework results in confusion and stressful interactions.
Putting process ahead of product doesn’t serve us
In these cases, we product people may need to embrace a more linear, Waterfall approach. At Nonfiction we understand that Agile’s strength is that it is pragmatic above all things. We need to be willing to flex to collaborate across the organization. We need to respect that in some areas of the business a linear approach is actually going to work better. You need to be flexible and open to multiple ways of working. For example:
|When to Stick to Agile||When to Incorporate Waterfall|
|Design||Day-to-day user interface design and usability testing||Exploratory customer research into new products and features|
|Marketing||Aligning marketing strategy with the product roadmap||Delivering features that are the focus of marketing campaigns|
|Staffing||Design team training and performance reviews||Hiring a new employee|
|Sales||Sharing in-app analytics to inform sales strategy||Sales reporting, market analysis, and revenue forecasting|
Agile Principles That Work for Everyone
With all that said, there few of the 12 principles of Agile that we find to be nearly universal. They form a great common ground to bring groups together and work in interteam environments and projects.
Making the customer happy is something everyone in the organization can get behind, and this commonality can serve as a litmus test for decision-making that can work in both Agile and non-Agile teams.
This advice transcends linear or iterative processes and goes to the heart of teamwork and relationship building. Cross-functional communication is key and this kind of alignment will work under both models—even when operating simultaneously.
We believe in face-to-face time to facilitate understanding and avoid disconnects. Don’t hide behind Slack.
Just because a process is linear doesn’t mean there can’t be check-ins or reflections that can inform iterative changes. This advice works across the organization and should always be part of your process.
The goal is to constantly improve your product by improving your people.
Walk the Walk
If you want to be truly Agile, our advice is to get comfortable with being fluid enough to sometimes work linearly for the greater good. Don’t limit your focus only to the framework that your product team uses.
At the end of the day only one thing matters in Agile: getting the work done. And in the pursuit of that, pragmatism is everything.