I’ve tweeted a few times about a project I’m on over the past few months where I produced large volumes of wireframes and documentation.
Well-meaning people are replying to my tweets to let me know that Big Up Front Design means I’m Doing Agile Wrong.
There’s a lot to unpack from that—more than I can fit in a single post. Today’s post is one in a series of fight-me throwdowns I offer to you, gentle reader.
TRUTH #1 Agile is a software development methodology.
The 12+ software development methods that even Wikipedia groups into “Agile” are all based on the Manifesto for Agile Software Development.
The manifesto itself isn’t a development method either, it’s a list of four values and twelve principles for producing software in a world where (at the time) all software was done using the waterfall model. When it was created, there were no development methods that aligned with it.
The Agile Manifesto was a reaction to a problem where almost all software was developed by a client sitting down with a business systems analyst (BSA) to gather requirements, then the client disappearing into the ether. The rest of development—software architecture, implementation, verification, and then delivery—was done without the client in the room.
By the time the client returned to certify the software, one or both of two things had happened:
- The client’s priorities had shifted and the software they’d designed with the BSA no longer fit their needs exactly
- The whisper-down-the-lane style of development where each group tossed their understanding of the requirements over the wall meant the software didn’t meet the requirements’ intention and the software didn’t fit the client’s needs.
For those of us who lived in those dark ages, trust me, it sucked to spend years building something that, when you delivered it, caused a lot of yelling. It also sucked to design and define something that, when it was delivered, you couldn’t recognize.
The Agile software methodologies, Scrum in particular, tend to embed a Product Owner in with the development team to iteratively provide requirements for the next most important part of the software. Through the Product Owner, the client always has a voice at the table.
The team captures the requirements, builds them, and delivers them for approval by the client, usually in 2-3 week “sprints”, so the client is always on board with the finished-up-to-here product.
If the business climate changes (whether it’s feature set, requirements, or budget), the Product Owner can ensure that the next sprint’s work aligns with the new priorities, so that fewer useless things are delivered.
TRUTH #2: UX is a product design process.
User Experience Design is not a software development practice. It’s a design practice.
The goal of User Experience Design is not to develop products. It’s to design products.
It’s to answer questions like:
- Who are the expected users of this product (and do we have data to back that up)?
- What do the users value in the experience?
- How is the product organized to deliver those values?
- How does the product look and feel to deliver those values?
- How does the user interact with the product to deliver those values?
Regardless of which methodology a development team is planning to use to deliver the product, their job gets easier when the client knows the answer to the questions above before the team starts building.
Not every UX project gets built, or is intended to be built.
Just as an architect can draw up the plans for a building that never gets built, a UX Designer can design a product that’s never built. In fact, roughly half of the projects I’ve worked on never shipped. Some were exercises in exploring new audiences where the business client decided there wasn’t a good fit yet. Some were situations where we discovered the complexity of the product put its price tag way above what the client wanted to spend. Some looked like fantastic ideas, but the users had zero interest in the products.
TRUTH #3: There are many ways to layer a Design process with a Development process.
UX Design is itself an iterative process. Research, sketch, discuss, adjust, repeat. No Designer nails the design on the first try (and they should be suspicious if they think they did).
Some UX Design is appropriate for layering into an iterative development process — in-sprint, or in-Kanban or whatever your development methodology of choice is.
Some UX Design is more appropriate to do in a big up-front chunk before the development team is engaged.
In a later post, I’ll differentiate between those two.
In either case, none of the design methods are, by definition, Waterfall or Agile, because those are development methodologies.
CONCLUSION:
If someone tells you that whatever design process you’re using “is not very Agile”, the correct response is “of course not, because this isn’t development.”
Go to the next post on this topic, Doing Agile Wrong: Two Big Up-Front Designs.
