We call what we do Information Architecture. We don’t call it information engineering or information development. The word “architecture” is intentional.
So here goes, I’m just going to say it: Unlike software engineering and software development, Agile doesn’t really work for Information Architecture. It can get in the way. In some cases, it can cause damage.
Let’s look at the architecture part of IA to understand why. At Factor, we always try to keep in mind that there’s a difference between building the thing right, and building the right thing. We didn’t invent this concept –far from it– it has a long heritage. We’ve heard many pioneers in the IA field talk about this notion; Laura Klein, Peter Morville , Dan Klyn , among others. Richard Saul Wurman an architect who coined the phrase information architect, before the field really existed, has talked around this notion quite a bit, as have many in the traditional architecture field.
But the voice that’s had the most impact on those of us at Factor is Jorge Arango. Like Wurman, Jorge found his way to IA from an original background in architecture in the traditional sense – designing things in the built environment.
Jorge points out that to design the right thing, you have to ask a different set of questions that you do to design the thing right. Agile methodologies and techniques aren’t typically equipped to ask questions such as (to list just a few):
- “What’s the opportunity cost of the things we’re taking on?
- Who are we accountable to outside of the organization? (This includes our ethical responsibility to nurture healthy societies.)
- What models and practices are impeding our ability to see reality clearly?”
Building architecture differs greatly from working in digital mediums, and that necessitates a difference in methodology. You can’t just start arranging stones (or today glass and steel), and iterate your way to a building that humans can safely inhabit. That approach won’t just waste a ridiculous amount of time and money. In fact, you’ll be lucky if it doesn’t actually kill people. (Or kill your building-physical-things business.)
That’s why our work focuses on building foundations. Now, some of our customers find this challenging. They’ve built something in a digital medium where the stakes don’t seem to be life or death. The gurus of software development have been preaching the gospel of Agile to them for so long that they believe rapid iteration is the only way to success.
And who would argue? They’ve been making money (usually by selling advertising, let’s be honest) so why change?
Perhaps because it’s not sustainable? Over the decades, I’ve seen this approach lead to the accumulation of so much design debt that it limits what’s possible. This leads to one “lipstick on a pig” design sprint after another, until
- suddenly the business or competitive landscape shifts or
- the organization decides it needs a new strategic direction, or
- there’s an acquisition, or
- any other myriad conditions and…
Oops! Suddenly you can’t fix one thing without breaking a dozen other things. The infrastructure is so brittle it begins to collapse under its own weight.
Worse, I think Agile, ironically, creates an accountability bubble. Agile is intended to be a regime of extreme accountability. Check in every day to see if we’re doing our work right or making progress or accomplishing our tasks. Use software to monitor the progress of every line of code. Get scrum-certified to optimize your participation in the accountability engine.
But let’s reflect again on one of the questions Jorge proposes that we ask:
- Who are we accountable to outside of the organization? (This includes our ethical responsibility to nurture healthy societies.)
You know what? It’s so easy for individuals to be accountable to the internal Agile regime that the whole organization evades accountability. Everyone feels so comfortable working the backlog that nobody raises their hand to ask “is this thing we’re building really efficiently going to be… Usable? Useful? Marketable? Flexible? Durable? … Sustainable?”
“But,” we hear folks say “if we just ruthlessly focus on customer data to inform our design decisions, we’ll be fine!” You shouldn’t ignore customer data–far from it–but over-reliance on it can actually make the problem far worse. Constantly chasing metrics in search of incremental improvements reinforces the impulse to iterate at the expense of, well, evolving. This is why so many companies fail to anticipate broad paradigm shifts in customer behavior until these shifts become existential threats to the business itself.
“The gurus of software development have been preaching the gospel of Agile to [our customers] for so long that they believe rapid iteration is the only way to success.“
Does this mean we should throw out Agile? Absolutely not! Once there is a robustly architected foundation in place, some form of an Agile or Agile-adjacent methodology is usually a critical ingredient in improving, refining, and maintaining a product or service.
But it’s not the right tool for every job. It’s not the right tool for Information Architecture itself. IA is a practice that needs to maintain a long view outside of the relentlessly incremental pressures of Agile methodologies. In fact, just as in the built environment, it’s almost always essential that there’s an architectural team that is not the same as (but still has excellent communication with) the team that’s doing the building. They should work together, but if IA’s are working within an Agile-oriented software development or UX design practice without autonomy and the power to effect change, they’re just cogs in the iterative machine.
I’ve seen this a lot over the years, but this is just my POV. What has your experience been trying to build foundational information architecture in Agile or Agile-adjacent environments?
