“You can’t have dessert until you finish your dinner.” Sound familiar? From an early age, we’re trained to finish one phase of a project before starting the next. But when it comes to launching a new product, this is a sure-fire way to fail.
The backstory
In the bad ol’ days, the golden-standard for project management was the Waterfall Method. You’d start by identifying the distinct stages of your development process: planning, design, implementation, testing, and launch, for instance. You’d only “waterfall” down to the next stage once you’d completed the previous one.
Usually, you’d keep track of a project in a Gantt chart, which would allow you to assign a start and end date to each phase. You could spent hours planning each and every task, assigning them to different team members, and budgeting for their time and work. In the end, you’d have a pretty impressive spreadsheet.
In the abstract, the waterfall method sounds pretty great. Why not plan everything out?
The problem
It’s impossible to predict how long each phase will take. When someone calls out sick, Planning gets postponed for a week. Your team needs another technician for Implementation, but she can’t start until next Friday. You realize the packaging needs to be redesigned, but it’s too late because you’re already in Testing.
This isn’t poor planning. This is real life.
Gantt charts become inaccurate faster than you can fix them. Companies waste time and money planning and replanning, budgeting and rebudgeting… and yet projects still end up behind schedule. The result: unhappy customers.
Worst of all, you might spend years building a product that no one even wants. But you couldn’t have known that until you finally launched.
The solution
In the 1980s, the Scrum / Agile / Lean methodologies were born. (Each term comes from a different historical background, but they all stand on the same essential principals.) The main goal is to reduce waste. Wasted time, wasted money, wasted opportunities.
Scrum / Agile / Lean does this by constantly iterating between three main phases: build, measure, learn. You build something and put it in front of real customers. You measure the impact. You assess what happened and learn from it, planning what to do next. Then you build again.
A team will typically complete one iteration of the build-measure-learn cycle in just one week. This single iteration is often referred to as a “sprint.”
The goal of the sprint is not to build a perfect product. The goal is to build something. Something real that can be launched and tested. Then, based on what you’ve learned, you build something else that can be launched and tested.
The result
1. You always have something to put in front of the customer. No more waiting years to find out if someone will buy your product.
2. There is tangible data to guide your decision-making.
3. It’s easy to pivot if you learn you’re heading in the wrong direction.
4. Your team has a constant sense of progress.
Despite the apparent value of planning, the iterative cycle of Scrum / Agile / Lean leads to faster, cheaper, and better results. Not to mention happier teams and customers.
———————
Action items:
〉 Identify a long-term project you (or your team) would like to invest in.
〉 Define what you will build (software? community programs?) and how you will measure it (bounce rates? revenue?)
〉 Determine the length of your sprints, and get started!