Assembling a team of capable technical partners starts with understanding the tasks this team will undertake. The software development process involves five phases:
- Planning
- Design
- Development
- Testing
- Deployment
Each of these five phases breaks down into subphases as well. Planning may involve customer interviews, prototyping, or other forms of research. Design involves both User Experience (the way our software presents information and receives input from the user) and User Interface (the way it looks and feels). Development may require some sort of architecture work up front—time spent defining the components involved and how they’ll interact—in addition to the process of writing code. Testing can involve both automated, software-based processes and manual, human-based ones. And Deployment requires preparing servers, releases, and monitoring systems.
Traditionally, these five phases were approached one at a time. We’d plan out our entire project upfront, including “V1” and “V2” scopes. We’d take that plan to designers, who would draft every single feature necessary to complete the V1 scope. Developers would take that design, architect the entire thing from top to bottom, and code features from the foundation up. Testing would only begin once the software was “feature complete,” and leaned heavily on manual Quality Assurance processes. Once approved, engineers would prepare that software for launch, manually deploying it to App Stores and the Web.
This approach, called the Waterfall Method, seems to just make sense. If you’re building a house, you start from the ground up. You don’t finish your kitchen counters before your architect knows where the living room is going to go. You start with a lot, architect your home, pour your foundation, frame the structure, and go on from there.
While it may feel comfortable, the Waterfall Method isn’t perfect. Approaching each phase separately introduces problems. Planning without input from our design and development teams makes it hard to get accurate time and cost estimates. Designing without engineering support sometimes leaves us with difficult-to-build or incomplete software. Developing the whole thing in one go is time consuming and expensive. Waiting to start testing until afterwards means bugs introduced early in the process may get covered up with later code, missed until after our software is already in users’ hands. And waiting until we’re done to deploy everything risks exposing our users to differences in our development and production environments, differences that can bring our launch to a halt.
Waterfall also leads to problems caused by “Product Telephone”. As our product vision moves from the founder through each one of these phases, minor errors get introduced—misunderstandings, miscommunications, or just mistakes. These minor errors build over time, often going unidentified until we’ve already spent the time and money to have them developed. The longer each goes undetected, the greater risk it poses to the project as a whole.
For these reasons, the software development industry has mostly abandoned the Waterfall Method. Instead, modern teams practice something called “Agile Development”.
What is Agile, Really?
Agile Development has become a bit of a buzzword. You’re unlikely to find a single development team in corporate, freelance, agency, or studio contexts that doesn’t consider themselves “Agile” these days (with the noted exception of domains like Aerospace and the Military where minor errors can cost people’s lives). Its ubiquitousness has made it difficult to pinpoint exactly what Agile is and isn’t.
For the most part, you can consider Agile the tactical cousin to Lean’s strategic approach. Where Lean is all about deciding what our highest value deliverable for each cycle is, Agile is all about how we can deliver that value efficiently. While every team has their own idea of what Agile means to them, the core concept is:
- Development cycles—called “Sprints”—are shortened: 1-2 weeks from planning to deployment.
- Deployment means delivery to customers: no spending months without shipping a working product.
- Each cycle’s scope is set at the beginning and remains unchanged until the cycle ends. That means no last minute changes, but also allows for course corrections every 1-2 weeks.
- Teams are integrated: if we’re going to go from planning to launch in 2 weeks, business, design, and development all need access to one another to make sure we don’t waste any time looking for answers.
What does Agile look like in practice?
- Each cycle starts with a two hour planning session, where business, design, and development leaders meet to agree on priorities and set the scope for the sprint.
- Throughout the week, designers and developers work to plan, design, architect, develop, test, and deploy only what’s needed to deliver the agreed upon scope.
- At the end of the sprint, the team delivers new features directly to customers for feedback.
While not explicitly required by Agile, competent teams also follow a number of practices that make delivering new value every 1-2 weeks feasible:
- Teams integrate junior, senior, and lead designers and developers to make sure the right person attacks each task.
- Developers accompany the features they code with a series of automated tests, guaranteeing that the features function correctly.
- Over time, these tests build into a larger “test suite” that verifies the entire application is working correctly after each change is made.
- Engineers use Continuous Integration/Continuous Deployment (CI/CD) systems to automatically deploy their tested code to a staging environment, ready for customer delivery at all times.
Its important to mention what Agile isn’t as well. In the 20 years since the original “Agile Manifesto” was written and published, an entire industry has been built up around the term. Companies like PMI provide (expensive) certifications for being an “Agile Coach”, “Scrummaster” and “Product Owner.” While there’s nothing wrong with these certifications, they’re not necessary for a team to be Agile—in fact, they go directly against one of the manifesto’s first declaration: “individuals and interactions over processes and tools.”
If you’re interested in learning more about Agile, the entire manifesto is available free of charge at agilemanifesto.org.
Benefits of Agile
For the non-technical founder, the benefits of Agile can’t be understated. Agile development means getting a functional product into your hands every 1-2 weeks. It means you need less upfront investment before taking that product to real customers and beginning the process of finding Product-Market Fit. It means no more “Product Telephone”: our integrated team is in constant communication with one another, meaning errors have less time to go undetected. And in the worst case scenario, they get caught at the end of our cycle.
It also means less exposure to the same kinds of risk we introduced while previously discussing Lean: faster customer delivery means less time for the market to move out from under us. It means reaching a new finish line every two weeks—if we run out of resources to continue development, we have a working product we can continue to take to customers. And it makes us more able to respond to external changes in the marketplace as well: with only this week’s features in progress, we’re able to course correct if Apple shuts down location apps or a global pandemic eliminates travel worldwide.
Agile development allows you to make small but significant improvements to your product every 1-2 weeks. Going back to our True Hockey Stick model, that means that just 3 months of Agile gives you 6-12 opportunities to accelerate your growth curve and move through your inflection point.
Agile development allows non-technical founders to bring new, functional value to their customers every few weeks, reducing the amount of upfront investment required ot bring products to market, and increasing the efficiency of their execution teams.
And the best part? There’s no downside. The same amount of work has to get done with Agile and Waterfall: we’re just changing the order in which we deliver that work. Even if you’re not interested in taking your product to customers after each sprint, you still get the other benefits of the process: fewer errors, less risk, and better communication.