Is Agile right for your next project?
Do you think it matters what project management framework you use?
It makes a huge difference for us. Not only do we switch frameworks a bunch, but we also tailor the method we’re using to the specific project we’re working on.
We’re usually choosing between Agile and Design-Build.
Here’s how I typically think about Agile. Agile software development is essentially a walkabout. The fundamental idea behind Agile software development is, we don’t know exactly what we’re building. As long as we don’t know what we’re building, why bother planning? Well, not exactly but close.
The classic argument against Agile software development compares it to building a house with no plan: “We’re not sure what the house is going to look like, but we’re certain it’s going to have a bathroom. Just start there.”
In this context, Agile sounds ridiculous. However, when we consider that most (if not all) startups aren’t sure of their product market fit, it begins to make sense.
When Agile works
Here’s something you can observe happening at MBA programs all over the country: An MBA convinces a software engineer to follow her in a foolhardy adventure and raises $150k to get started. What business are they starting? Don’t sweat the details.
So, the MBA and the engineer put their heads together and come up with a way for the engineer to makes some friends, sorry engineers. The MBA says, “how about swipe right, swipe left but for friends?” “Brilliant!” Exclaims the engineer.
So the team sets about building the swipe right, swipe left feature, buys some Facebook ads in their local town and get some initial users.
Second meeting: “So, guys are creeping and the girls just want to be friends… Perfect, we’ve rebuilt tinder.” “What about a time out zone for people who creep?” “Brilliant!” Exclaims the MBA.
This pattern continues for some time until the team either runs out of money or finds a profitable product market fit.
As you zero in on your product market fit, your adjustments get smaller and smaller. You begin optimizing your site for a better user experience, you refactor your backend to pay down your technical debt and make things faster. But in the beginning it’s not uncommon to make large business pivots and correspondingly large tech changes.
During this process you’re simultaneously designing the page views, building the features and spinning the data round and round.
This is commonly referred to as the build, measure, learn cycle and is at the heart of the lean startup methodology. And this is really where Agile sings. It’s adaptable when you don’t know exactly what you’re doing.
Let’s compare that to a Design-build process:
What’s design build?
Simple: first you design it, then you build it. One of our current clients, Kennedy & Company, is building out a streamlined financial aid application for schools. As the client is an education consulting company, they have a great deal of industry experience, an existing client base and a straightforward sales channel. It is fair to say, they have a good idea of what the minimum viable product needs in order to close their first deal. Additionally, streamlining the dreaded FAFSA form is not simple task.
Taken together: the client having a solid picture of the MVP and the MVP having fairly complicated features, designing the product before beginning development makes perfect sense.
Why? Because it’s cheaper to fix mistakes in the design phase than in the development phase. Does this mean when the first version of the product is finished, you’re finished? Of course not!
Design build can be thought of as the first cycle of Agile building. The only real difference is the granularity of the designs you develop before you start building. In Agile, you are much less granular than in a design build project.
Here’s how we think about which one to pick:
If you’ve got a clear problem your product is solving and a relatively simple MVP, design build is likely the way to go. If you’re attacking a market, rather than a problem you’re better off planning for some iterations in your development process.
