This Part 2 of a 4-Part series on Agile.
The purpose of this post is provide a bit of background on what Agile is and the conditions under which it emerged. Both this post and those that follow are targeted at UX professionals and researchers of all kinds who may be encountering these ways of working for the first time. It is focused on the application of Agile methods for software development, although Agile is also used in other work environments such as manufacturing.
So, for the purposes of these posts, Agile is a methodology for software development that is focused on delivering software more quickly and incrementally and with greater stakeholder involvement. It places a heavy emphasis on team engagement in planning, goal setting, and joint execution.
In the early days of software development, processes often mirrored those of automotive manufacturing, where all the requirements were defined up front, and then delivered in their entirety through to production. In the industry, these methodologies came to be known as Waterfall. In other words, the requirements cascaded from business stakeholders down a long chain through product managers and business analysts and technical analysts to the developers, who were then asked to build the solution based on written requirements. Unfortunately, the process was like a very expensive game of Telephone, where the extensive hand-offs made it nearly impossible for the developers to understand the underlying goals of the work they were tasked with.
Over time, it became clear that this approach led to all kinds of challenges – most notably long delays in getting a fully functioning product ready, and a significant disconnect between what was requested and what was actually built. As the high tech industry made a transition from technology for technology’s sake to a more fast-paced, market-centric approach, this would become increasingly problematic.
The advent of object-oriented programming enabled engineers to think of their work in smaller components, and also required them to find ways of working together more effectively. In the late 1980s and early 1990s, cost pressure in the industry required either developing software at a lower cost, or improving quality and throughput by finding better ways to deliver software. For more background on these pressures and the subsequent response by computer scientists, please see Lean, Agile written by by David Harvey in 2004.
In 2001, a group of individuals disillusioned with the prevalent software development practices got together and penned the Manifesto for Agile Software Development (below). The signers sought to evolve their work as engineers by ensuring they were adequately involved in understanding what they would build, and then remain engaged with business stakeholders and users throughout the development lifecycle to make sure that the product was not just technically sound, but that it also met both specifications and user needs.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Agile practitioners use some specialized language to describe their ways of working, which may make it challenging to engage with at first. The value of an end-user’s perspective today is generally understood and appreciated as being critical to the development process, but it is incumbent on the user-centered design and research professionals to both understand Agile practices and to find ways to engage effectively. I am writing this piece now because blogs – and the first books – are just starting to emerge about the ways that research and design professionals can contribute in this context. It’s an exciting, exploratory, shaping phase, so you too can contribute with your own experiences and insights!
In subsequent posts I’ll write a little bit more about the basics of Agile, and ultimately propose some ways that User Experience professionals can effectively engage in contexts where Agile practices are present.