Agile for Everybody: Why, How, Prototype, Iterate

A Practical Approach for Better Deliverables

An “agile” approach for everybody: Why, How, Prototype, Iterate. (Illustration by Joan LeMay)

For people working in software development, there is no shortage of off-the-shelf “agile” frameworks to choose from. These frameworks can be quite different procedurally, but they all share the same core set of goals: to facilitate cross-functional collaboration, to account for the inevitability of change, and to quickly produce working, testable software.

At their best, these frameworks provide critical tools for bringing collaboration and alignment to software development teams. But what about those of us who are not building “working software?” How can we bring the best of “agile” practices to everyday reports and deliverables? How can we reimagine “agile” in a way which works as well for service organizations as it does for product organizations?

Over the last couple years, my colleagues at Constellate Data and I have been experimenting with how to bring “agile” practices to our training, consulting and research work. And after much trial and error, we have found a lightweight framework that consistently leads us to better outcomes and shorter turnaround times:

1. Define the “Why”
2. Define the “How”
3. Create a time-boxed prototype of the final output
4. Iterate on that prototype

These four core steps — which we refer to collectively as WHPI (pronounced “WHOOPEE!” if you are so inclined) — constitute a kind of “minimum viable process” for everyday agile practices. What follows is a summary of each step, and a few notes on bringing this practice to your team.

1. Define the “Why”

One of the hardest lessons I learned as a product manager is that product development frameworks are essentially worthless in the absence of clearly articulated goals. A lot of great things have been written about the importance of starting with “why,” but it is shockingly easy to skip this step unless it is built into a formal practice, especially when navigating tight deadlines and evolving client needs.

For this step, we convene a small number of key stakeholders (2–4), and quickly iterate on a set of goals for the project or deliverable. When possible, we try to meet in a physically co-located space, and work with Post-it notes that are easy to discard and rewrite. We will often limit this session to 15–30 minutes. While this time limit may seem severe and inflexible for such an important step, it often reveals an important truth: if you can’t define your high-level goals in 15–30 minutes, then you probably need more information before moving forward. More than once, we have realized during this stage that we need to conduct some basic research to validate our assumptions, or that we should reach out to our client with a few clarifying questions.

Once a small number of critical goals have been established, we like to put these goals in a highly visible place: up on a wall if we’re physically co-located, or on the first page of a shared document if we’re working remotely. Sometimes, we will ask remote colleagues to actually write out these goals on their own Post-it notes, and stick them to the top of their computers for the duration of the project.

For example, when we are designing an executive summary after one of our workshops, we might wind up with these three high-level “why” Post-its:

• Communicate sense of project momentum to senior leadership
• Remind participants of key “a-ha” moments from workshop
• Generate interest among colleagues who have not yet attended a workshop

2. Define the “How”

After establishing project goals, it is important to decide how you will actually accomplish them. We sometimes refer to this step as “defining your instruments” — now that you know what you’re trying to do, what tools and approaches are you going to use?

We recommend moving directly from “why” to “how” with the same group of stakeholders. Often, in defining the “how,” it becomes clear that one or more of the team’s high-level “why” goals is actually an execution-level “how.”

For example, in the previous section we set the following “why”: “Generate interest among colleagues who have not yet attended a workshop.” Before we started utilizing this practice, we defined a similar goal this way: “Provide participants with language and frameworks to share this work with their colleagues.” But once we started separating out the “why” from the “how,” we realized that we were missing two key questions: why is it important for people to share this work, and what is the best way to achieve that goal? Are language and frameworks actually what people need? Might we be better off creating a separate shareable document and sending it directly to participants, or identifying a new cohort for a follow-up workshop? These are the very kinds of questions that help lead to a clearly articulated “why” and an actionable “how.”

With the “why”s from the last section in place, we might agree upon the following “how”s to guide execution work:

• Use pull quotes from participants to communicate sense of momentum to senior leaders
• Use photographs from workshop to remind participants of “a-ha” moments
• Lead with positive outcomes and limit play-by-play to keep deliverable focused and generate broader interest

Clearly defining these “instruments” and keeping them tightly tied to high-level goals provides a mission-critical roadmap for the execution work that follows.

Once you’ve decided upon “why” and “how,” put these front and center as you move forward with creating and iterating upon a prototype.

3. Create a Time-boxed Prototype

With the “why” and the “how” defined, it is time to create a time-boxed prototype. The word “prototype” can mean a lot of different things in a lot of different contexts. For the purposes of this practice, we define a prototype as follows:

• A prototype is not an outline or a planning document; it is created in the same format as the desired deliverable or output. For example, a “prototype” of a presentation supported by slides would be a presentation supported by slides. A “prototype” of a print brochure would be a print brochure.
• A prototype is created within a fixed and finite amount of time. (Which is to say, it is “time-boxed.”)

To put it in more narrative terms: “Create something that achieves as many of the project’s goals as possible (“why”), using the approaches and instruments we’ve agreed upon (“how”), in the same format as the desired output and in a limited amount of time.” For a small project like a marketing one-sheet, this initial prototype might emerge looking and feeling like a finished first pass. For a larger project like a 40-page report, this initial prototype might be 20 full-sized pages folded in half, stapled together, and filled in by hand with page and section titles, brief summaries, and image placeholders.

We began using this approach after a year or so of fumbling through complex planning documents and detailed outlines. While creating these documents often felt like “doing things the right way,” things that looked great in outlines and planning documents didn’t work as well in presentations, reports, and workshops. To use a classic example, a list of ten strategic bullet points might look great in a planning document — but as soon as you throw it into a PowerPoint deck, it becomes much less effective as a means of conveying information. By prototyping the deck itself first, you’re making sure that the information you provide and the format in which you provide it are well-aligned from the outset.

We usually assign one team member to create the initial prototype. Oftentimes, this simply becomes a matter of capacity: who has a few hours in the next couple days to take a first stab? We’ve found that two hours works very well as a default prototyping time-box — it’s enough time to create something that can be evaluated against the project’s goals, while leaving plenty of room for improvement and iteration.

4. Iterate

After the first time-boxed prototype has been created, the initial team of stakeholders (or some subset of that team) meets to review the prototype and provide feedback to guide the next iteration. We started out doing our feedback using a plus-delta format, but eventually retooled it slightly into something we call “protect, omit, and refine.” After the prototype is presented, stakeholders share three types of feedback:

• The things that should be protected in future iterations, because they most directly meet the desired “why”
• The things that can be omitted in future iterations, because they do not seem to contribute directly to the desired “why”
• The things that might be refined in future iterations, because there are specific and actionable ways in which they could better move us towards the desired “why”

The key difference between this approach and a traditional plus-delta is the explicit inclusion of things that can be omitted in future iterations. We began pursuing this approach when we found that, even when working on a fairly large project, the most successful iterative changes tended to be more subtractive than additive. Making “omit” an explicit part of the feedback and iteration loop encourages participants to look for things that can be cut, resulting in more concise and focused deliverables. And framing all three types of feedback by how well they adhere to the agreed-upon “why” helps resolve potential disputes, avoid hurt feelings, and keep the project on track.

Once feedback has been collected, a team member is assigned to incorporate this feedback into another tightly time-boxed iteration of the prototype. In some cases, this involves directly reworking the last prototype (such as revising a PowerPoint file). In other cases, this involves creating a new prototype based on prior prototypes (such as creating a deliverable report in Microsoft Word based on prior hand-written prototypes). These subsequent rounds of iteration can be handled by the same person who made the initial prototype, or by a different member of the team. By the second or third iteration, the prototype often winds up in the hands of the very person who is ultimately responsible for sharing or presenting the finished product. And, by the second or third iteration, the prototype is often surprisingly close to done, and ready for whatever final polish it requires.

A Few Notes on WHPI in Practice

We have been using the WHPI practice consistently for the last six months or so, and we’ve found that it has greatly improved both the quality of our deliverables and the speed at which we produce them. If you are interested in trying this approach with your team, here are a few points that we have found to be important and useful:

• Sometimes the “why” will change midway through a project or deliverable. That’s ok! Because this is an iterative cycle, you can always add or remove a “why” during the feedback stage of an iteration, and reconfigure your “how” accordingly. This new information can inform the plan for the next iteration without derailing progress on the project overall. And, because you have captured and preserved the “why,” these changes — and what they mean for the project — are always clearly understood by the whole team.
• The “how” might seem like the easiest step to skip — but every time we tried skipping it, we wound up having to do more iterations of the prototype. The “how” connects the project’s goals to the prototype itself, and makes it easy for anybody on the team to do the first round of prototyping.
• We’ve found prototyping to be particularly valuable for large-scale projects and deliverables. Prototyping a 40-page deliverable report in a few hours may seem like a less obvious step than creating a comprehensive informational outline — but a comprehensive informational outline can’t tell you much about how well the actual experience of thumbing through a 40-page report will meet the project’s goals.
• During the iteration loop, be sure to keep feedback laser-focused on what meets the project goals. Early in this practice, I focused too much on trying to make the prototype seem impressive in its execution, and we developed the protect/omit/refine framework largely to facilitate the shedding of impressive but unproductive “junk.”
• When we started doing this, we often found ourselves asking, “wait… does this actually mean we’re done?” after a few very short and tight loops. If you have to ask, the answer is usually “yes.”

This practice has helped move us towards those same “agile” goals I learned as a product manager: to encourage collaboration early and often, to bring visibility and clarity to project goals, and to generate a “working” prototype as quickly as possible. We’ve used this practice for everything from workshops to meeting agendas to deliverable reports, and I’ve also found it helpful for other aspects of my creative life such as songwriting and cooking. (Seriously!) Give it a shot, and drop me a line at matt@suddencompass.com if you have any questions or want to discuss how we can help your team adopt “agile” practices for everybody.