Agile UX – Collaboration and Delivery
Agile was created by enterprise developers and looks at the software product from a developer perspective, similarly to how someone working in a restaurant kitchen looks at the restaurant at large. It’s not that the stuff going on in the front of the house, the experience part of the restaurant, isn’t seen as important, it just isn’t the primary focus. Furthermore, in the enterprise world of old, which was a primary focus of Agile, software products were more akin to an institutional cafeteria anyway, ie highly utilitarian systems where the focus is on delivering the required features rather than a great user experience. As Ward Cunningham, one of the original signatories of the Agile Manifesto, once said at an Agile UX retreat at Cooper, “Agile is hot food served quickly.”
Ultimately, Agile is about high-quality high-velocity delivery of working software. In the Agile universe, that is the ultimate measure of success. However, a funny thing happened on the way to that Agile Manifesto. Making great software quickly, it turns out, requires collaborating really really effectively with those pesky non-binary entities called people. While basically silent about UX design, Agile thinking offers a fundamental paradigm shift about how to interact and communicate with the people on your team and beyond.
So, while there certainly is a lot that UX designers can learn from Agile thinking on software delivery (such as to automate everything that can be automated), the real pay-off for UX practitioners is in the collaboration part. Agile UX methods, like Design Studio and Cross-Functional Pairing, help UX practitioners replace slow documents with fast and effective direct interaction. An Agile UX practice, in other words, replaces document-centered practice with one that is collaboration-centered. This is a very big deal for UX designers working on Agile teams, because it is this shift that is key in allowing them to integrate their practice with Agile Developers.
Lean (Startup) UX – Measuring and Validating Product/Market Fit
Cool, so now we’ve got this great Agile machine allowing us to be crazy-efficient in shipping software. But, um, did anyone check to see if we are shipping the rightsoftware? A Lean UX approach shows us that shipping, which basically is the big honkin’ Done in the Agile world, is in fact really only the beginning. While Agile methods help UX designers turn old ways of designing and communicating on their head, Lean UX helps us overturn old approaches to research and measuring quality.
In a traditional model, research is something you do before starting to create the product, to figure out what the product is that you are going to build. In a Lean approach, we are continuously building and gathering metrics about what we have built. The most archetypal example of this is the metrics-gathering landing page, which is created and launched at the very outset of the project, rather than soon before the “finished” product is about to be released. We turn what was once just seen as marketing fluff into an actual experiment of our hypothesis that others will think our idea is as great as we think it is. Then, the metrics gathered from that landing page (or it can evolve into a full-fledged metrics-gathering website) are fed back into the product design.
But a landing page is just one of any number of ways one can apply Lean UX. Another common pattern is to create a simple prototype and GOOB! or ”Get Out of the Building!” Many UX designers give lip-service to the idea of User-Centered Design, but don’t actually spend a lot of face-time with real users. Regardless if they do, GOOBing both rebrands and reshapes the idea of UCD and also gives UX designers a nice kick in the butt to get out of their cozy cubicles and offices and actually take their ideas to where the users are.
We are, in this model, not doing research before or after the product is made but throughout the product design and delivery process. While in an Agile UX model, Building is Designing is Building, in a Lean UX model, Building is Research is Building, and it is easy to see how these two are very much intertwined. Like with Agile UX, it allows for much more easily integrating research with how Agile teams work, since it is continuous and not up-front.
One more thing about Lean UX: I think it’s kinda’ confusing. The term “Lean” has its origins in Lean Manufacturing and refers to the practice of minimizing waste and maximizing flow, which, in turn, is a cornerstone of Agile methods. Lean UX, on the other hand, is really a reference to Lean Startup a la Eric Ries (and Steve Blank, basically the godfather of Lean Startup, and creator of concepts like Customer Development and Getting Out of the Building), which extends Agile ideas to include methods for ensuring that there in fact is a market for the product you are doing such a good job designing and shipping early and often.
Bottom line: in everyday conversation, whether one uses the term Lean or Agile or what-not is probably not important. What’s more important is an understanding of how Agile and Lean help make traditional UX a more whole practice.
From Agile UX vs. Lean UX by Anders Ramsay