Doing Agile Wrong: When is Big Up-Front Design Right?

In my last few posts, I explained that I’ve been tweeting about a Big Up-Front Design project and folks have been replying to me that I’m Doing Agile Wrong.

In the first post, I explained that Agile is a development methodology, not a design methodology, so of course my design process isn’t “agile”.

In the second post, I explained that there are two kinds of Big Up-Front Design, one being in the field of UX Design and the other being in the field of Software Design. The second is the riskier of the two because it depends on the first.

Today we’re going to get to the meat of the issue: when is Big Up-Front UX Design appropriate?

TRUTH #1: Any product design requires people to talk to each other.

I’m a big fan of the Agile Manifesto (as long as I’m not looking at it too closely) and its four values are useful not just for development but also for design.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

If the Manifesto is Agile’s Ten Commandments, then its golden rule is “Stop throwing shit over the wall and talk to each other.”

I’m pretty sure that’s good advice for everyone.

Regardless of how we decide to integrate design and development, a tight collaboration between the Business Client, the UX Designers, and the Development Team is key.

A sketch of how Business, UX Design, and Development work together
A sketch of how Business, UX Design, and Development work together

TRUTH #2: Big Up-Front Design isn’t always needed.

Team A is building a new feature on a well-established product. They’re using Scrum as their Agile methodology of choice. For Team A’s project:

  • The business lead assigned to the project knows what the business goals are, has a good idea of the user base, and has even done some user research in advance of the project.
  • The changes should take less than 6 months of development, and easily break into multiple drops.
  • The development team’s stable, cohesive, and cross-trained. They’ve worked with the Business Lead and the UX Lead before.
  • The company’s brand standards are established and codified in code snippets and components.
  • Company risk is low if the product isn’t adopted.

A reasonably good UX Designer can easily integrate Design activities into the development team’s Agile process.

  • The UX Lead works with the Business Lead to confirm user research and/or strengthen it in Sprint 0.
  • Sprint 0 is also where high-level wireframes are hammered out and anything unique that isn’t in the component library or brand standards is researched.
  • During sprints, the UX Designer provides detailed design by iterating on the wireframes (usually 1-2 sprints ahead) and providing guidance and/or QA testing for the developers.
  • When the project’s done, the UX Designer has a library of what changes were made and when in the form of wireframes that can be reused for support or maintenance (along with the stories and/or requirements docs.)

Team A doesn’t need Big Up-Front UX Design. There are very few unknown or risky items in their project, they all work well together, and they’re an experienced team. Even a low-tenure UX Designer would likely become comfortable on this project.

TRUTH #3: The more risks there are, the more important an up-front design is

Team B is also building using Scrum as their methodology of choice, but their product isn’t well-established, it’s brand new. There are lots of questions about what Team B’s building which the client hasn’t answered yet.

  • The company has a notion of what they want and a budget, but no business processes to support their still-undeveloped ideas.
  • The new product requires the six stakeholders to all change the way they do business, which is expensive and messy and requires internal change management.
  • The six stakeholders’ business leads are all assigned to the project, they have conflicting business goals, and none of them have done any user research.
  • The primary decision maker arrived with a launch date set in stone — less than one calendar year — and a highly-entangled complex feature list that would take 3 years to code. Everything is a “must have now”.
  • The development team’s a junior team, where people are promoted to other positions once every six months or so, and new blood is always coming in.

Nobody, and I mean nobody, wants this team’s designer making critical information architecture and process mapping decisions in-sprint, where they can change every few weeks based on new revelations in information and structure.

Nobody wants the client to still be defining the product during Sprint 8.

No one wants a delay when the designer comes up with the right decision but nobody knows how to code it because it’s not componentized and it has to be approved by Brand.

And absolutely no one wants to rebuild 6 months of work on a looming deadline because we just realized that a critical piece of the architecture could be simplified or restructured or removed or whatever and it’s already built.

When most of the project is still a mystery stored inside the business’s head, the best thing a development team can do is send a UX Designer off for 1-3 months to codify the goals to the point that development can be successful.

TRUTH #4: UX Visioning is iterative, just not always at the same time as development

The UX Visioning process is just as iterative as Agile, and with many similar principles:

  • Get a high-level definition of what we’re aiming for by providing early and continuous delivery of wireframes and sketches
  • Research the user and business goals. Are they the right goals?
  • Create the architecture. Can it be broken up for delivery? What pieces have dependencies on each other? What must the users truly have to succeed?
  • Welcome changing requirements, even late in design, so the dev team is coding the right product
  • Spend time discussing decisions that have value and impact on the end user, not the ones tied to design dogma or business politics
  • Work together daily with business people, developers, and if you can, end users.
  • Get the best right people in the room
  • Buildable designs are the primary measure of progress
  • Simplicity – the art of removing unnecessary items until the design is finished – is essential.
  • The best designs emerge from teams that agree on the user goals and compare designs to those agreed-upon goals regularly

When Big Up Front UX Design is done well, it results in a high-level strategy that can help the Scrum Master and the team decide on the epics and features. It can set a brand direction and design decisions for any level of skill on any team. It sets the tone for interactions with the team and gives the business a clear voice into the product direction.

It lowers development risk. It lowers business and development cost.

CONCLUSION:

Big Up-Front Design is not for every project. In a company with an established stable of products, it may happen rarely if at all. And that’s OK.

Big Up-Front Design adds the most value when the business goals and user needs are undefined or in contention, the product complexity is high, and/or the development team is less experienced.

Big Up-Front Design is a tool for lowering project risk, not increasing it, and using it is neither commentary on Agile nor “Doing Agile wrong”. It’s a methodology that, like all methodologies, has its place in our Design toolboxes.