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.
Strategy
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.
