it agile

When something is wrong, it deviates from truth or fact. And I can say, with more confidence than ever, that traditional Agile software development methodologies (i.e. Scrum) are wrong for UX. In order to prove my case, I want to take you back to the inception of Agile (as I have read and experienced it) and its related software development methodologies. Along the way, we’ll point out the reasons these methodologies are incompatible with the field of User Experience Design.

The birth of Agile

Agile principles and related methodologies were created for several reasons. Perhaps one of the bigger reasons was in response to the problems of the waterfall software development methodology (the most popular methodology in use up until this point). The waterfall methodology involves defining all system requirements and designs before beginning to build the software. Once these requirements and designs are defined and signed off on, the development team begins to build the software to spec. However, because of its rigid, separate phases, this system proves ill-equipped to handle the changes that can come about as new ideas arise and requirements evolve. This inability to handle change throws off build time and costs in a big way. Thus, the problems of waterfall include high costs in development resources with low return in quality code. Simple put, waterfall proves bad for business.

From this, Agile principles were born. These principles include: 1) a focus on adaptive methodologies, 2) a focus on people and 3) a focus on self-adaptive processes. Different methodologies utilized these principles in order to create working software more rapidly and iteratively to decrease costs and increase quality. And, that is something that Agile methodologies do very well. They enable businesses to make software cheaper and faster, and they also help to incorporate more user feedback in the process. So, why am I saying the methodologies born out of these principles are wrong for UX?

The argument

The second principle of Agile is a focus on people. This must mean that there is a focus on user experience design, right? Wrong. At least, this is wrong for many of the adaptive methodologies that we are putting into practice when we say we are “doing Agile”. Agile methodologies do focus on feedback from users to help create a higher quality and more usable product. However, what you’ll note is that nowhere in the above story of Agile’s birth was any other participant in the software development lifecycle mentioned except for the development team. The focus in creating these agile methodologies was simply on making the development process more efficient. UX was not even an after-thought (It really wasn’t. We had to butt our heads in and keep reminding them that we existed. Nod your head if you agree… Ok, you can stop nodding.) Thus, Agile principles are great, but the adaptive methodologies that employ these principles do not take into consideration anyone else but developers (and stakeholders… someone’s gotta pay for the work, afterall). Furthermore, there is an important reason why these methodologies don’t take anyone else into consideration. Put simply it is because Agile adaptive methodologies are software development methodologies, not product development methodologies. Thus, Agile methodologies were not designed for, nor intended for UX practitioner participation.

To make matters worse, our businesses have latched on to Agile methodologies as a way to decrease costs and increase production. Because of the appeal of saving money, decreasing time and increasing quality, the business hasn’t stopped to really think about how Agile methodologies should be employed, and the effects of employing them incorrectly. The result is that they have confused software development with product development. They are trying to substitute software development methodologies (Agile’s adaptive methodologies) for product development processes in hopes to speed up the entire product development lifecycle. Therefore, the business cuts out any thought of upfront product validation and research, as well as, any product strategy work because these processes are not “part of Agile”. Ultimately, by the business trying to replace product development processes (where UX contributes the most value) with Agile methodologies (which weren’t designed to include UX in the first place), we see UX processes and procedures get pushed out of product development all together (are you pissed off yet?).

Please let us play

In the fury of switching to Agile methodologies, UX does not want to get left behind. Therefore, we keep trying to fit ourselves inside of Agile methodologies (Note: Some companies and startups have found a way to do this very well, but most are still lacking). Most of the time, UX is looking for ways to ensure we are involved, and are thus constantly compromising our processes and beliefs in order to stay relevant. In the process, we lose more and more of the value that we bring and make ourselves more and more irrelevant. We decide that research doesn’t need to be as extensive as we think (and yes, sometimes this is true), and so we cut down on it. We decide that design thinking can be sped up and so we skip through that. Basically we are doing everything to ensure we don’t get kicked off the playground and sent home.

The solution

Obviously, Agile isn’t going away (for good reason), and UX can’t just stop trying to bring our knowledge to projects. So, how do we solve the issue mentioned above? I think the first step is truly internalizing the issue, that of businesses using Agile methodologies for product development. We need to realize that Agile methodologies are great for software development, but are not great product development.

Second, we need to become educated about the difference between using Agile methodologies for product development versus for software development so that we can educate our businesses to this fact. And, how do we educate our clients and businesses about this? Easy; we tell them how they are wasting their money trying to fit a square peg into a round hole. Businesses have employed agile methodologies to decrease costs (see Learn the Business Behind Our Business for more thoughts on this), but using them incorrectly will only increase costs in the long run. By applying Agile methodologies to product development, something they were not designed for, businesses are dumping money into an investment which will yield a small return. Because they are disregarding upfront research and strategy, they have no idea how their product will sit with users and this is a huge risk (for more info see How to Know When Your Product is Going to Fail). They are also using the wrong resources for the wrong responsibilities at the wrong time, and this is even more costly than returning to waterfall!

Third, we need to design a solution that works, for everyone, and then sell this to our businesses. This might mean a methodology that includes Agile principles in its build methodology (see The Secret Step to Agile: Discovery for initial thoughts. Slides also available), or it might include an entirely different thought all-together. But, we have to have a solution to product development that is cost effective, user effective and tech effective in order to push out Agile as the reigning product development solution. Agile is meant for software, not products…. we have to spread this message.

The aftermath

Once we educate our businesses and help them to see the error in their ways, some important outcomes occur. We get a change in the system of how products are developed that allows UX to exert its value, Tech to exert its value, and Business to be successful. Agile methodologies don’t reign as product development methodologies, but continue to evolve along with their related software development methodologies. This helps to create software cheaper and faster, but also software that is relevant, delightful and useful. But, UX can only get there if we cause a shift in the times, and that shift is the outcome of us changing our ways from people just trying to get invited to the party, to the people who are throwing it. The choice, is ours.