Despite the promise of flowering fields of innovation, efficiency, and manageable chunks of working software, you should be cautiously optimistic in applying the agile philosophy to your practice of information architecture.
One counterproductive practice in agile software development has persisted since the original publication of the Agile Manifesto: agile planning gives little regard to user experience strategy or information architecture—two pillars of sound requirements gathering. Instead, backlogs of requirements fill up with a never-ending stream of ill-informed requests that provide the basis for user stories. To accommodate the barrage of irrational objectives, information architects and other UX professionals who find themselves working in such an environment must resign themselves to becoming flexible—which means giving up any hope for coherent guidance in exchange for pure bedlam. Teams that are plagued by such strategic malpractice must develop a high threshold for pain and ambiguity.
Now, I’m sure bedlam was not what the original authors of the Agile Manifesto had intended for developers when they crafted their persuasive agile mindset. They were realists who were at the mercy of business sponsors and product managers who were under the influence of changing market conditions, short-range thinking, and prolonged and frequently flawed requirements gathering processes, and had an anemic understanding of human-to-computer interaction. So, it makes sense that a group of bright developers would agree on the value of team interaction,customer collaboration, and embracing change—as a means of speeding up the process of getting to working software. These worthy ideals were more than foundational to agility, they were essential to the software developer’s survival.
However, constantly operating in survival mode can be taxing. This is why the agile philosophy requires some additional ingredients to be sustainable in practice. Ironically, we can sometimes best realize the promise of agile within the context of process, documentation, negotiation, and planning—the explicit things on which the Agile Manifesto places less value. But, regardless of any formal approach that you may use to rein in agile activities, your organization will likely measure the value and progress of your work in working software—that is, code. This is no surprise because the Agile Manifesto’s historic roots lie within the context of computer science and engineering.
While agile philosophy is not necessarily exclusionary to other disciplines, the software engineering community has by far the most influential voice in defining agile methods—though industrial manufacturing was its main source of inspiration. For agile software development to continue its successful run in the market of digital business, it must improve the participation of non-engineers—specifically, information architects and UX professionals.
Over the last two decades, software development has continually evolved. We now understand that it is not possible to engineer successful user interfaces solely from business requests and that we must instead intentionally design their projected user experience. In this technological age—when software is running on everything and everybody is using it—we must now consider the definition of working software from perspectives that go well beyond just code and the prescribed requirements of product or business owners—who have little or no direct experience in designing for diverse human factors across digital ecosystems. Despite this lack, product owners are still typically the keepers of the sacred requirements documentation in agile development contexts: the user stories. This brings me back to my first point.
If a Scrum product owner or Kanban requester is incapable of leading a product team because of their lack of a disciplined perspective on the design of user experiences and information architectures, you can expect your agile team to spend cycle upon cycle struggling to make sense of strategic ambiguity, creating working code for user interfaces that don’t work for people, tweaking user interfaces serving shallow use cases, fixing usability issues that you could have avoided, and maintaining poor Web structures that you should completely rebuild.
A successful agile design and development team whose goal is to create products for people should carefully consider the competency of its product owners. For, in the end, the product owner’s digital vision will determine the level of the bar that gets set for working software and user interfaces. Convincing your organization to shift business accountability for the digital experience to UX and IA professionals who have proven strategy and leadership skills will require education, trust, and time. But this is the direction in which we must now progress. At some point soon, we’ll have to insist on this.
For now, the march to making quick, iterative software improvements is endemic. Regardless of whether large companies are prepared for this, they are listening to their IT constituents, who advocate the use of agile engagement models like Scrum and Kanban. But, as IT departments deliver their ultimatum on agility to executives, many may not realize that they are inadvertently asking the business for the help of sound IA and UX leadership in producing requirements with greater and much needed fidelity. If you’re working for or are being recruited by an agile organization, here are a few things to consider:
- Agility is architected. Be sure that your agile team follows a formalized and disciplined process. If it doesn’t, you may find yourself in an unhealthy state, struggling for survival.
- A sustainable information architecture is not self-organizing; it is grounded in intent. Be sure that business requests recognize both the needs of the business and its targeted users.
- While it’s possible to deliver IA solutions with agility, it’s difficult to architect a sustainable solution without understanding the content, the context, and the human factors of users. Whenever necessary, do research that fits within your team’s sprint cycles.
- Don’t tolerate chaos. While the Agile Manifesto does give less importance to process, documentation, contract negotiations, and planning, any credible agile approach has a process, requires documentation, follows a plan, and allows negotiated terms. These, in turn, enable effective estimation, prioritization, and task assignments.
- While operating without a plan in the face of uncertainty and ambiguity forces you to be agile, it’s usually ineffective. Advocate for developing a clear strategy to empower agility and eliminate ambiguity in execution.
- Agile methods are about managing and optimizing productivity, assuming that the appropriate long-term strategies are in place. If you’re an information architect or UX professional who gravitates toward seeing the big picture, challenge yourself to break down your vision and recommendations into smaller chunks in the spirit of agility. Taking this valuable step will help you to improve your iterative approach to design, which is inherently susceptible to short-term thinking.
Can information architects and other UX professionals bring value to an agile culture? Certainly. Everyone in an organization—from the cleaning crew to the CEO—can benefit from adding a little agility to their professional toolkit. The question is: how much and when?
Information architects and UX professionals must develop complementary methods of working that embody agility and demonstrably lead to user interfaces that work at the human level. So, view your relationship with agility as a work in progress and do just that—make progress.