Nature - Intertwingled: Information Changes Everything - page 16

find the right fit. If we fight culture, it will fight back and usually win. But if we look deeper,
and if we're open to changing ourselves, we may see how culture can help.
For example, information architects are often associated with what the Agile software commu-
nity calls Big Design Up Front. And it's true that in the early days of the Web, our wireframes fit
nicely into the sequential process of the waterfall model. We created blueprints for websites be-
fore designers and developers got involved. Many of us would have preferred a more collabor-
ative, iterative process but were constrained by management's step by step plans.
Since then, the context has changed. While we still plan new sites, much of our work is about
measuring and improving what exists. And when we do a responsive redesign, for instance, we
know wireframes aren't enough, so we work with designers and developers to build HTML pro-
totypes we can test on many devices. We've learned to collaborate with colleagues and work in
diverse ways. So, at a deep level, there's no tension between information architecture practices
and the principles of Agile. In fact, as an information architect, I find the Agile Manifesto relev-
ant and inspiring.
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan. xiv
And Agile aligns perfectly with systems thinking. It's not that we shouldn't begin with a plan
and a process. Both are still important. But, today's sites and services are sufficiently complex
and dynamic, many eyeballs and iterations are the only way to fine-tune the whole system.
This systems-friendly philosophy also lies behind the adaptation of lean manufacturing to soft-
ware. In the 1950s, Toyota figured out how to avoid the pitfalls of mass production by embra-
cing what's now called Lean. xv In design, all relevant specialists were involved at the outset, so
conflicts about resources and priorities were resolved early on. And in production, managers
learned that by making small batches and giving every worker the ability to stop the line, they
could identify, fix, and prevent errors more quickly and effectively. Instead of serving as cogs in
the machine, workers were expected to solve problems by using the five why's to systematically
trace every error to its root cause. Similarly, suppliers were expected to coordinate the flow of
parts and information within the just-in-time supply system of “kanban.” This transparency en-
sured everyone knew a missing part could stop the whole system. In short, managers gave
workers and suppliers an unprecedented level of information and responsibility, so they could
contribute to continuous, incremental improvement. And it worked. Quality soared, and Toyota
became the largest, most consistently successful industrial enterprise in the world.
In recent years, Eric Ries famously adapted Lean to solve the wicked problem of software star-
tups: what if we build something nobody wants? He advocates use of a minimum viable
product (“MVP”) as the hub of a Build-Measure-Learn loop that allows for the least expensive
experiment. By selling an early version of a product or feature, we can get invaluable feedback
from customers, not just about how it's designed, but about what the market actually wants. It's
a holistic approach that recognizes the risks of vanity metrics such as total number of users. As