Behind all the certifications and seminars, the idea behind Agile is relatively simple:
- Build something your customers want
- Ship it fast
- Change it based on feedback
Even if you don't want to become fully Agile certified, a workflow that incorporates aspects of the Agile methodology—a small-a “agile” workflow—is a good idea for virtually any team to adopt.
When most teams start projects, they start as ideas. Someone thinks up something the customer might want, and then they pick a crew to tackle the execution. Work is assigned. Deadlines are set. Twenty status meetings later, you're no closer to being done. The deadline's been pushed back. No one even knows whether the customer ever wanted this feature at all anymore, and the whole team is left feeling demoralized.
With agile, every potential feature or improvement in a project is tagged with the function it serves, the utility it provides to the customer, and its prioritization in the product. You spend a week or two feverishly working on a predetermined list of these tasks during a sprint—then take another few days, or a week, to refresh and reflect on what you did. Then, you listen to what your customers tell you and make changes accordingly.
With an agile workflow, you learn faster and ship faster—and waste less effort.
How agile helps
Agile has conceptual roots in the “lean” manufacturing methodology, first pioneered by Japanese automakers in the middle of the 20th century.
The idea behind lean was to reduce waste—get rid of any wasted motions and movements, and you can lower costs and increase your profits.
Say a worker on an assembly line has to bend over to pick a part off the ground and bring it up to his waist hundreds of times a day. If the assembly line could be altered to bring that piece to the worker already at waist level, it could save a tremendous amount of effort. It would allow that worker to accomplish more while wasting less time and energy. Altering the line might require an upfront investment, but in the long term, it would be worth it.
Agile transplanted these ideas to the world of product and design, where the goal of the process was less about optimizing the output of an assembly line and more about creating new, innovative things. Today, the ideas behind Agile are so ubiquitous that we can speak of a small-A “agile” workflow—inspired by, but not totally beholden to, the original Agile system.
At Wistia, for example, CEO and cofounder Chris Savage brought the agile methodology together with a mountaineering metaphor. It's a spin on agile that lets the team get stuff done in a way that fits the unique Wistia culture:
Because each project and each team are explicitly defined by discrete, month-long chunks, we’re able to iterate our processes over time to improve how we work together, and to more precisely direct the ways in which the company evolves. After every summit, we sit down together and talk about what worked, and what didn’t. This lets our system correct itself over time: the routine feedback we give each other lets us constantly work on improving our team operations.
At Wistia, sprints last four months—they're called summits—and they're followed by a period of reflection known as base camps.
You'll find similar iterations of agile workflows across companies everywhere. Asana has Roadmap Week. Basecamp works in four-to-six-week cycles of Small Batch and Big Batch projects. Each is a unique spin on the idea of the agile workflow. To get started building your own customized agile workflow, you'll just need three basic ingredients: a backlog and stories to fill it; sprints; and standup meetings.
Backlog: where you organize your stories
Everything agile begins in the backlog. This is where all of the raw, brainstormed ideas that you put together internally and from customer feedback come together, get tagged and annotated, and eventually find their way into sprints.
Each idea starts with a user story—the story of the feature or improvement as told by the person who will actually be using it.
Writing a good user story means creating a narrative about the purpose the feature or improvement will serve and why it’s needed. To ensure the requirements for the feature are clear, record both the literal function of the idea (what it does) and what it helps them accomplish (the use case) in your user stories:
As a user, I want [feature] so that [use case].
Whoever is in charge of the product owns the backlog of ideas. It's their responsibility to maintain standards for the backlog (you may want to add further tags for new items) and most importantly, prioritize each item in the list.
Every item in your backlog as a product manager should have:
- A priority ranking
- A description of the function of that item, i.e., what it literally does
- A description of the use case of that item for the customer, i.e., what it helps the customer accomplish
- A status indicator (Started, Not Started, Done)
- A directly responsible individual, or DRI
Your backlog should be a collection of ideas that are:
- Well-articulated, with a clear relevance to the customer
- Tightly scoped, so they're feasibly achievable within the period of a “sprint”
- Truly prioritized, rather than “all important”
The stories in your backlog should be able to come from anywhere—customer success, sales, engineering, design. Anyone who interacts with the product or with customers gets a sense of the kind of features that make sense to build.
That's why the best way to fill your product backlog in a hurry is to create a form that anyone at your company can use to add stories.
Make sure all submissions are tagged with the function of the feature (what it explicitly and literally does) and the use case (what problem that solves for the customer). A priority field is optional here—you might not want the people adding forms to have much say in the ultimate priority of that story. There are, also, many additional fields that you might want in a form like this to further specify and tag the different stories you're adding to your backlog, like:
- UX element being addressed (e.g. landing page or splash screen)
- Domain (e.g. marketing or sales)
- Any blocking stories (i.e. features that need to be completed prior)
- Any engineering notes
Prioritize your stories carefully. In the product development process, your stories are your raw materials as well as your individual tasks. They are what actually gets done when you embark upon your sprints, which are the next main layer of abstraction in the agile workflow.
Sprints: where you execute on your tasks
Sprints are the “getting stuff done” part of agile—they are time-boxed periods where teams work on a set of predetermined backlog items in order to accomplish a goal.
Each sprint begins with the choosing and prioritization and grouping of items from the backlog, lasts for a certain amount of time, and ends with a retro—a meeting where the team reflects on its work and begins to make preparations for the next sprint.
At minimum, a sprint should contain and be tagged with:
- The stories that make up that sprint
- A start date and a target end date
- A description of the goal of the sprint
- A status indicator (Planning, In Progress, or Completed)
- A directly responsible individual, or DRI
A DRI, or directly responsible individual, is critical for making sure that the sprint gets planned out properly and proceeds according to deadline. The agile workflow is quick, and deadlines can fly by if teams aren't supervised. The DRI makes sure that milestones are hit.
That DRI may be the same person who prioritized the stories, or it may not. Either way, someone needs to decide what stories go into the sprint, and which get left out. This second part is important. Try to fit too many stories into one sprint—and test your target release date—and you risk throwing the whole product calendar off.
Any new concept for a sprint needs a name, a goal, and a targeted release date.
Then, to get the sprint ready, go through your backlog and add the appropriate stories.
A sprint is just a period of time on the calendar, of course, without the glue that makes up most agile workflows—standups.
These don't need to be, and shouldn't be, long meetings involving a half-dozen staff. They should be quick, tactical rendezvous points—at which discrete objectives are carried out.
Standups: where you keep everything running smoothly
A standup is the opposite of the kind of meetings you might be used to. For starters, you “stand” to keep it short. These aren't the kind of meetings where you get comfortable, or sleepy, in your chair.
Standups are designed to get a job done quickly. Some teams like to do them every day during a sprint. Some teams prefer to do them once a week. In our base, we've left the question of how many sprints and what kind up to you, but we've started with three basic types:
- Planning: held at the beginning of the sprint, to assign roles and responsibilities and clarify all tasks
- Weekly: held throughout the sprint to get updates on progress and find ways to unblock members of your team that are blocked
- Retro: held after end of the sprint to reflect upon progress and assumptions and improve for next time
Some combination of a planning meeting, a retro meeting, and a recurring “progress” meeting makes up most of the agile workflows out there.
The planning meeting kicks off the sprint, and the retro caps it off, helping you process your learnings and apply them to the next sprint. The cadence of the progress update meetings in between is up to you—they're mostly for making sure that the project is progressing at the right speed and you're on track to finish on time.
Each meeting needs to be tagged with:
- The date of the standup
- The type of standup
- The directly responsible individual, or DRI (who runs the meeting)
- The participants (who are needed for the meeting)
- Meeting notes
You can view all of your different meetings in a calendar view, and even use Zapier to send your meeting dates to Google Calendar so you can automate the scheduling of your planning/progress/retro standups.
> Check out our compiled list of 7 essential product management tools
Just enough Agile for agile
There are infinite ways to plan a project and infinite ways to execute on it. While the concept of an all-encompassing system to cut down on those choices is appealing, most companies have established ways that they best do things like create complex software products.
You don't need to toss out all of your existing practices and replace them with a whole new system to become more efficient and waste less of your team's time and energy. Don't get caught up on “big-A” Agile—embrace the small-a.