Avoiding the Pitfalls of Agile with High Fidelity Prototyping

A couple of weeks ago, we talked about the history of Agile software development and some of its weak points. Largely, these stem from Agile’s iterative approach to doing product design in code, which can leave teams without a clear goal when making decisions, planning resources, and driving consensus and understanding.

Prototyping at the beginning of a project can help mitigate some of these Agile drawbacks. Prototypes can simulate product features and user experiences at a high level of visual and interactive fidelity, all without code. And prototyping ahead of other development tasks provides teams with clearer guidelines for the rest of the project, reducing technical debt, improving communication, and driving a better final product.

We’re not suggesting that prototyping solves all product development problems, but when implemented early in the project, prototyping can significantly reduce the scope of changes once development begins.

Read on to learn how to avoid the top five pitfalls of Agile with medium and high fidelity prototyping.

1. Prototyping Enables Better Technical Decisions

Agile methodologies commonly recommend that software be designed progressively and iteratively through a cycle of writing code, showing the product to customers, getting feedback from them, and then rewriting the code. While this is a good way to ensure that the software is user-focused, it can lead to piecemeal code and technical debt.

Have you ever started building a piece of furniture and decided part way through to make a change? You then proceed to disassemble as little of your work as possible to make the change. As you progress further, you realize you’d like to add another drawer. Instead of taking the whole thing apart, you put in a couple extra nails and shave a little off the piece. When you’re done, it looks great… but you try to move it as little as possible.

Software development in an Agile environment can often feel this way. Because Agile is skeptical of the notion that a cohesive solution can be designed ahead of development, developers are asked to do their best with limited information and to expect change. They may have all the tools and resources needed to build a piece of software, but the less they can foresee what the final product will look like, the more likely it is that getting to that final product will involve a lot of false starts and unstable code.

So what do we do with all of this technical debt? One option is to ignore it. (If you’ve ever worked on a product with a lot of technical debt, you probably don’t think this is much of an option.) The second is to clean it up or rebuild it after the fact. It’s an expensive and time-consuming option if there’s a lot of debt, but it works.

But why not just try to keep debt to a minimum to begin with?

The idea that you can’t make informed, longer-term design decisions is misguided. You certainly can, and it doesn’t require an abundance of documentation either.

The solution here is to create medium-to-high fidelity prototypes as part of the design process. You can gather feedback and iterate on a functioning prototype in the same way you would with working code. This allows you to hash out a longer view of an application’s design before asking developers to start writing code. And because the prototypes represent a more complete goal for the application, developers can work through their sprints with the broader application architecture in mind and code solutions that make sense at both the micro and macro levels.

The result? Less debt. Cleaner, more maintainable code. Better product.

2. Prototyping Gives Teams a Motivating Goal to Work Toward

Let’s return to our furniture example. Before deciding to buy and assemble your new dresser, you probably saw it in a catalog or showroom. You liked its bare wood finish and the modern design of its handles. You checked its dimensions to ensure that it will fit perfectly between the bed and the window. Seeing the product and imagining it in your bedroom helped motivate you to buy and build this dresser despite the cost, time, and possible frustration of taking on the project.

Agile doesn’t always provide this valuable motivation. Most people want to know what their efforts are contributing to, and they want to know that their work will be valuable and appreciated enough to justify those efforts. When a feature or product is designed iteratively during the development process, and the vision of the future product is deliberately ambiguous, the team lacks an inspiring goal to work toward. Worse, the team can lose faith that a worthwhile result will be reached and become frustrated as people pull in different directions. Aside from the human cost, this can ultimately result in lower productivity and lower quality code, and it can even contribute to developer turnover.

This Agile pitfall can be bridged by using high fidelity prototyping to iterate, test, and validate a product’s design with customers and stakeholders ahead of development. A prototype represents a vision of the product. It is the dresser in the showroom that you can’t wait to own even if it takes hours to assemble. Developers can look at it, interact with it, and get excited about building it.

3. Prototyping Enables Project Estimates and Resource Planning

If diving into development without a finish line is a problem for team morale, it’s a disaster for budget and resource planning. When you design a product on the fly as you’re building it, it’s impossible to predict how much time, money, and people it will take to achieve the business goals. (Is the finish line Sprint 50? What if Sprint 35 uncovers some new requirements?)

Some stakeholders and clients may be comfortable with unbounded budgets and ambiguous outcomes. Congratulations if you’ve achieved that relationship with your stakeholders! But even in those cases, businesses benefit from predictability — and frequently demand it. Without it, it’s very difficult to have a plan. If you’ve ever worked in an Agile environment and it felt like management was constantly shifting priorities and abruptly ending projects, this lack of predictability could be the reason.

Identifying a desired outcome early in the pursuit of a business goal can go a long way toward providing reasonable estimates to stakeholders and instilling confidence. Prototyping is a great way to define the desired outcome before starting development. By testing and iterating with prototypes, you can make informed choices about what needs to be built to accomplish the goal… and what doesn’t. Once you have a good sense of the Epics and Stories, you can estimate the time and resources needed to get there.

4. Prototyping Eliminates the Need for Inefficient Meetings

There’s room for a lot of misalignment in software development. Customers have to communicate their workflows and needs to researchers and analysts, who in turn have to parse and translate them into requirements for UX designers, who have to propose solutions to product managers… and so on down the line to developers writing the final code for the application. Each exchange is a chance for misunderstanding and deviation from the goal. Ensuring that everyone “gets it” throughout the project is hugely beneficial, if not essential, to reaching a good outcome for all.

In keeping with the Agile Manifesto’s Principle #4 that “business people and developers must work together daily throughout the project”, Agile teams attempt to facilitate communication by encouraging as many face-to-face interactions as possible. This has largely manifested as collaborative coding, daily standups, and frequent meetings with high attendance. In theory, these meetings are an effective way to answer business, design, and technical questions, remove barriers, and maintain alignment. In practice, however, they can lead to rushed decisions and turn into a drain on time and morale.

Let’s take a closer look at collaborative coding. On the surface, a product owner sitting next to (or near to) a developer as they code seems like a great way to get product and design questions answered quickly and ensure that you’re building the right thing each day. And it can be! But if this process becomes a bandage for not sufficiently vetting an idea before starting development in the first place, we have a problem. The collaboration turns into frustration, and the value dissipates quickly.

That’s where prototyping comes in. Medium or high fidelity prototypes ensure that you aren’t seeing your ideas come to life for the first time when the developer hits “build”. You’re able to answer the big questions in advance and reserve coding time with developers for the relatively quick ones.

What about the highly attended meetings? This mostly happens on teams that have many specialized roles: product owner, product manager, UX research, UX/UI design, front-end developer, back-end developer, devops manager, QA lead, etc. And the Agile way to stay up to date on a development effort is to meet. A lot can be accomplished in those meetings if everyone is on the same page, but a lot can go wrong if even one person is not aligned. Answer: prototyping. It’s not perfect, but it is an effective way to demonstrate a proposed solution that just about everyone understands.

5. Prototyping Provides the Benefits of Documentation Without Being Just Documentation

The Agile Manifesto is famously anti-documentation (or at least it’s commonly interpreted that way):

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.

In other words, when faced with the choice, you should spend your time building something tangible instead of creating lengthy Word documents that historically became obsolete quickly. Makes sense. While there’s no doubt that working software is ultimately the goal, “documentation” offers many benefits that shouldn’t be written off.

First, documentation is an effective supplement to face-to-face meetings, chat messages, and emails when communicating with developers — especially if those developers aren’t down the hall, as is often the case in our distributed world of software development.

Second, maintaining documentation for a software project supports organizational memory. (No, I didn’t make that up.) It’s a way to collect and share all of the knowledge and decision-making that goes into a software product. The “Who”s, the “Why”s, the “What”s, and every other W. This is invaluable for onboarding new teammates and for ensuring that clients, marketing, product support, and other teams can have insight into decisions (and context for those decisions).

Third, maintaining product documentation may simply be required by your client or for satisfying compliance requirements. This type of software development governance can be especially important for software teams working in finance, healthcare, and government.

That said, mounds of text-based documentation describing flows, interactions, user interfaces, and functionality are rarely considered a great way to convey that information efficiently. Fortunately, prototyping once again offers a solution. If your team uses medium and high fidelity prototyping to design your product, the prototypes themselves (including any past versions) serve as a visual and interactive set of documentation. And because it’s a prototype and not production code, you can incorporate notes and documentation in the context of the prototype. Learning about the history of a feature doesn’t have to require interpreting paragraph 238 of the PRD.

Medium and high fidelity prototyping gives Agile software teams a way to do what Agile does best — build user-centered software through testing and iteration — but without its biggest pitfalls. Agile methodologies have historically pushed for experimentation in code and working software at the expense of all else, but only because the sophisticated prototyping tools we have today didn’t exist when the Agile ball first got rolling. But now with the abundance of research, design, and prototyping applications available, we have a better way to design and build software.