The Agile Method for Food: Rocket Fuel For Culinary Development

How I accelerated my food development by adapting software development’s most popular project management workflow.

When chefs talk about developing recipes — they usually focus on the technique or soulful artistry of the craft more than the workflow they followed. Creativity and talent will continue to be where the magic lies, but the way that you approach the PROCESS of development can have a massive impact on the quality and velocity of output in a commercial setting — especially when working in teams.

As a chef-turned food-tech entrepreneur I have had the opportunity to lead both food and digital product development teams simultaneously.

Having one foot in the kitchen and the other in tech allowed me to realize that the two disciplines require a remarkably similar organizational skillset, and can follow a very similar framework for workflow.

Following an “agile methodology” — which is the go-to approach for software development — allows you to break complex projects into several smaller phases, combined with a structured workflow that involves constant collaboration, time-boxing (called “sprints”, which typically last 2 weeks), and working itteratively.

I have found that the Agile methodology can be adapted for the food industry to massively accelerate the impact of the food development teams that I have worked with.

TL;DR: “Agile for Food” is a structured project management workflow for rapid development in a team environment.

Phase 1: Collect ideas/tasks, prioritize them, and define details of what will be developed.
Phase 2: Plan a 2-week working period (aka “Sprint”) where the highest priority tasks are developed. Estimate effort of each task and empower the team to commit to who does what work.
Phase 3: Execute the 2-week Sprint with daily check-ins (called “stand-ups”) and 2 primary stage-gate approvals. Finish with a retrospective meeting on work accomplished and a discussion on improvements and move directly into planning the next 2-week Sprint cycle. Repeat indefinitely.

Note: I want to be clear, this article covers a system for managing the development process itself and does not cover the ideating phase. High quality ideation through research, brainstorming, and down-selection is obviously essential to the precede this process. This article focuses on the “How” not the “What”.

Why “Agile for Food”?

Agile for Food is my adaptation of the Agile methodology for the food industry. It follows the same basic framework as the software development version, but I have simplified it overall and tweaked a couple of terms to better fit the food industry.

Agile for Food offers a few key advantages:

Higher velocity of output and learnings
Development becomes a predictable cycle
Priority is based on value to the customers and the business
Work is done in small, iterative stages to allow for quick feedback and rapid, imcremental improvements

1. Agile for Food Workflow

Getting work done follows this basic process:

2. Agile for Food Roles & Responsibilities

Regardless of team size, it is essential that these three roles are formally identified. It’s perfectly acceptable to wear multiple hats where it makes sense:

Product Owner: Manages the Backlog and represents the stakeholders (e.g. corporate management). This role doesn’t need to be the final decision maker but should act as the advocate of what is delivered to the decision maker.
Project Manager: Serves as a facilitator of the Agile rituals, ensuring that the team follows Agile practices and continuously improves their processes. This role is often filled by someone who is close to the day-to-day operations of the development process and can act as a project manager overseeing the status of tasks.
Product Development Team: A cross-functional group of experts delivering a potentially releasable products at the end of each Sprint. Depending on the organization, this team could be comprised of chefs, food scientists/technologists, nutritionists, and product marketers.

3. Product Ideas (aka Product Stories)

A product idea should ideally be articulated in the form of a “Product Story”. A story is a brief, plain-language explanation of the product. Software development writes these from the perspective of a user, but since food development doesn’t deal so much in empathy of experience I suggest using a more straightforward framework for Product Story formulas:

[product main idea] that [specifics about the product].

Product Story Examples:

A light-and-bright crispy chicken for the spring that incorporates baby potatoes and ramps inspired by “X-restaurant”.
A gluten-free variation on the chocolate peanut butter protein bar that incorporates berries that achieves the same texture.
An indulgent plant-based broccoli sandwich with a vegan chipotle-lime mayo for the lunch menu.
A green vegetable side that contains less than 30mg of sodium.

Product Ideas are placed into the “Backlog” by the Product Owner or Project Manager. The Backlog is simply a collection of tasks in a queue that the team has not yet started worked on.

4. Backlog Grooming

“Backlog Grooming” is the process of prioritizing the ideas based on value to the business and customer to ensure the team is always working on the highest value work each sprint. We also work collaboratively to make sure that the requirements for the product are clear and easily understood. Value is determined by:

Value for the customer
Alignment with business objectives (strategic goals for the company like improved customer satisfaction, increased AOV, or improved margin)
Value for other stakeholders (e.g. Cross-Functional Departments, Corporate Management)

Backlog Grooming Meeting:

A “Backlog Grooming Meeting” is between the broader cross-functional team including Product Owner, Project Manager, and Stakeholders/Management to decide on (and adjust) priorities for what gets worked on.

In this session you can add/remove/fine-tune Stories, adjust priorities, or reevaluate estimates.

I cannot stress enough the importance of this meeting enough in achieving cross-functional alignment of priorities. I would encourage you to invite Corporate Management to these meetings — transparency goes a long way with alignment.

5. Refine Product Requirements

“Requirements” are the gathering of key elements for what the product needs to be successful. They often include sometimes comprehensive write-ups of key ingredients, skeletons or comps for recipes/formulas, descriptions of processing methods, target cost/margin, presentation instructions, etc. Consider it a plan for how to execute the item at the bench.

6. Sprint Planning

The “Sprint Planning” meeting is where the Team will review the highest priority items in the Backlog, and consolidate into work that can be achieved within the time-box your organization determines.

Software development favors 2-week sprints, but in my experience food often has lead-times and requires sometimes days between development attempts. Although it might be tempting to extend the sprint to longer durations, I encourage you to stick with the 2-week sprint framework.

2 weeks injects a feeling of discipline and momentum into the development process, and if by the end of the Sprint more time is required, the Product Owner can place the Product Story back into the Backlog to be addressed during the following Sprint.

The Sprint Planning Process:

The Product Owner identifies items not completed in the previous Sprint and the items at the top of the backlog.
The Product Owner calculates the Team’s current Velocity, based on the previous Sprint’s estimates and completed work.
Team Members start by identifying why (if any) product stories were not marked as completed from the previous sprint.
Team Members review the product stories in the backlog for understanding of the requirements. Tasks are identified for executing the story; these can be simple tasks like “slice chives” or complex tasks like “establish optimal time/temp/delta program for the sous vide 6.2oz Smoked Duck Breast”.
Team Members assign Story Points to Stories they are assigned.

Story Points:

Each member of the Team provides an estimate for size of the task called “Story Points”. Typically a numerical value is assigned so the total points can be summed and measured for the individual and team’s total output.

Points should represent the size, complexity, and effort needed for completing the Story — the higher the number of points, the more effort the team believes the task will take.

A common framework in Agile for Point value is the Fibonacci Sequence.

In the Fibonacci Sequence, each number is the sum of the previous two in the series: 1, 2, 3, 5, 8, 13, 21, 34, 55… and so on. This framework is used to better perceive jumps in effort when the numbers get larger. The goal of story points is to act only as a guide to help your team gauge how much time a task will take and how many resources you will need to devote to it.

For example, a task to develop a simple variation to an existing item — like creating a spicy version of a dressing for a salad concept with many other similar products — this may be a 2 or 3.

But if the task is more complex — like creating an item with a completely new piece of equipment or processing framework that requires grinding through technical complexity — it may be assigned a 21.

Measuring Individual and Team Velocity:

“Velocity” is used to quantify and analyze the output of the team during one Sprint. If Story Points were estimated effectively, it’s a simple way to measure productivity based on how much work is accomplished.

The goal of Velocity is not to simply quantify the differences in output of Developer 1 vs Developer 2, it’s to accurately predict how much work should be scheduled into a given Sprint given current team’s resources.

Tips & Tricks to increase Velocity:

Avoid context switching — try to keep Product Developers focused on a narrow range of tasks (e.g. it’s more efficient to focus on one product category than multiple)
Cross train everyone — if everyone knows everything and is constantly training you will get more done. There are always going to be specialists, but with Agile it’s ideal if everyone can be assigned any type of work.
Focus on impediment removal — One I see a lot is not being able to develop because a product is not in house to test — a major blocker that can often be avoided.
Experiment with pair work — Sometimes 1+1=3. Try out ways to pair people together to produce greater results.

Sprint Commitment:

Once enough items have been estimated to complete the Team’s Velocity (both from carry overs and new items from the backlog), the team is asked if they are “comfortable committing”.

The “Sprint Commitment” is a verbal commitment by the Team to take on the estimated work for the next 2-week sprint period. Commitment implies intent to complete ALL of the work and is made by consensus.

It’s an important step for buy-in and accountability of the team members.

If “yes”, the Sprint is Committed and cannot be changed.
If “no”, negotiation and analysis is performed to break tasks down into a commitment the Team is happy with.
Note on Velocity; if recent sprints have been under committed (meaning finished early) the team may elect to attempt a higher velocity for the upcoming sprint (or vice versa).

7. Daily Standup Meeting

The purpose of the “Daily Standup” is to align development activities towards the goals of the current sprint. Each member of the development team will address the following three questions:

What did you accomplish yesterday?
What are you planning to accomplish today?
Where are you stuck?

Some guidelines for this meeting:

Do not discuss solutions to problems extensively in the meeting; solutions should be handled in break-off sessions outside of the Daily Standup.
Attendance is mandatory. If members cannot attend, they should provide a colleague with their update so they can present them to the team.
The Daily Standup is not a status report for management, it is a statement of intention between team members to build collaboration, focus effort, and identify risks preventing work from being done.

The meeting is led by the Project Manager, who keeps track of progress and impediments, and will create breakout sessions to address issues. The Product Owner is not required for this meeting, but can be a passive participant if the team requires clarification or would like to solicit opinions. And last, but most importantly, the meeting should last no more than 15 minutes. The allows the team to focus on the work, solving problems, and being productive, rather than simply allocating time for a meeting.

8. Ad-hoc Tasting Reviews

Food is so subjective, and as a food product developer you often can experience “Palate Fatigue” when you eat anything repeatedly. Soliciting the opinions of others through “Ad-hoc Tasting Reviews” is an essential step to gather qualitative data on how good your product is, and if adjustments are required.

Ad-hoc Tasting Reviews are performed for any product at any stage of development by Development Team Members with the assistance of other Team Members. This step is an extremely useful check-in to gather early feedback on how the product is developing.

These tasting reviews should be treated as informal feedback to help strengthen your development process and should be performed on a casual basis as many times as deemed necessary.

9. Acceptance Tasting — Mid-Sprint Review

The “Acceptance Tasting” is a progress check-in conducted once a week on a recurring day & time. Members of the team meet to discuss and align on the current Sprint’s progress by formally presenting the items to the Product Owner.

The goal of the Acceptance Tasting is to evaluate if the products meet the quality requirements of the organization and the needs of the customer. Any feedback or corrections from the Product Owner during the Acceptance Tasting are noted in an update and returned to the Product Developer who created the item for further refinement.

A reminder: no product should be abandoned at this point, regardless of the outcome of the tasting — the full 2-week Sprint cycle should always be kept intact. There will be an opportunity to adjust priorities and remove Product Stories during the next Sprint Planning session.

10. Approval Tasting — Final Sprint Review

The “Approval Tasting” is a meeting between the Development Team and Stakeholders (including the Product Owner, Decision Maker/Corporate Management, and other optional people invited by the team) to review the completed products prior to final approval and commercialization.

This meeting consists of a presentation of the completed items by the Team Members for the Stakeholders. Stakeholders should provide explicit feedback.

At this point, the supplementary materials of the product are required for review. This can vary based on the organization, but generally include:

Recipe/Formula w/Process Instructions
COGs estimates (food cost, labor cost, packaging cost)
Nutrition
Sensory Notes
Marketing Name / Product Description

The Product Owner records the feedback in order to create new tickets for the Backlog to be addressed in future Sprints.

Notes from the Approval Tasting is recorded formally and shared in the subsequent Sprint Retrospective meeting.

Please Note: It’s common for there to be several layers of approval in different organizations that can occur either before or after the Approval Tasting. For instance, costs may need to be formally approved by a Finance Team, or Sensory Notes by a QA team, etc. And a formal handoff will likely be required to Marketing, Supply Chain, and Ops Teams prior to kickoff of the commercialization process and launch cascade.

The approvals during the Approval Tasting can be adapted and should not negate the existing process requirements of your organization.

11. Sprint Retrospective

The “Sprint Retrospective” is a meeting that occurs directly after the Approval Tasting. It acts as a postmortem from the completed Sprint. Three major topics are raised for discussion:

Review lessons learned in the prior sprint (the sprint before the one just completed) to analyze if they were satisfactorily mitigated in the concluding sprint.
Identify new lessons that were learned during the sprint by the team (negative lessons learned).
Highlight anything that worked extremely well and should be integrated into future sprints (positive lessons learned).

Anything that affects how the team develops food products is open for debate. This might include processes, practices, communication, environment, organizational tools, and equipment.

Troubleshooting Existing Live Products Should Be Handled Separately.

Similar to bug fixes in tech, troubleshooting live products should be considered to be outside of the sprint. The team must keep a certain percentage of bandwidth to ensure they have time to address issues with existing products (Schedule only 70% of Story Point Velocity capacity for instance).

The team decides when to handle live issues on a case-by-case basis. If the issue is critical and needs immediate attention, then it must be fixed during the running sprint.

From a project management perspective, Live Product Issues can be placed into the same project management framework as projects in the Sprint, but should be tagged differently to clearly define their separation (could be as simple as a red tag vs blue).

Project Management Tools I Would Recommend:

I find a digital project management tool to be essential for managing and visualizing product development, tasks, and priorities.

It’s also helpful to have the ability to store multiple pieces of information (e.g. attachments, images, links, comments, etc), and immediately translate your view into a GANTT-style roadmap/timeline. I guarantee your job will much easier than attempting to manage this on Google Sheets.

I have tried and can recommend:

Software Development-specific Technical Project Management tools like Jira or Zube have a lot of great features for Agile that could be adapted, but I’ve tried them and in my opinion they are overkill with unnecessary features and might have too steep of a learning curve.

Final Thoughts:

Agile is not a perfect framework for every team.

Your organization may not require a lot of new product development, or may work on a naturally slower schedule.

It also may not be practical to utilize if you have a one-person department, so feel free to modify to suit your business (e.g. no daily standup needed).

For those situations where Agile does not seem like a fit, I still recommend following some chronological framework such as Waterfall which follows similar pillars but is a bit more conservative with more linear stage-gates which could also be a better option if your development is non-recurring. I will cover Waterfall for Food in more detail in a future article.

Never lose sight of what matters most.

Agility alone is not enough. Not even close in the food business. Customer experience in the food industry is a highly sensitive and fickle beast that should be highly protected lest you risk damaging your business or sensitive relationship with customers.

I always recommend choosing quality over quantity with food, so factors like Velocity should be taken with a grain of salt.

Also be prepared that you will also increase the volume of failures in addition to successes. But just as the quote from John C Maxwell says:

“Fail early, fail often, but always fail forward.”

Great product development is fundamentally more about progress and resilience than isolated brilliance.

I’ve found this framework to be an amazing catalyst for progress that (if it’s right for you) can hopefully help take your food program to even higher heights.