How (not) to Scope a Project
Lessons from dreaming too big, when time is scarce
We were going to have a brilliant interface. It was going to use machine learning. And be built on a blockchain. Heck, we may even do an ICO! It would have user groups, and recommendations, and tokenization, and work with businesses.
Except it wouldn’t. Time is money, and we didn’t have either. What started as an extremely-ambitious project dwindled into a struggle to generate a working MVP on time. So what happened? How could it have been done differently?
I think, despite experience constantly telling me the opposite, that I stubbornly have an overly-optimistic view of what can be done in a short amount of time. Hackathons boosted this naïveté. After all, I’d gone from zero to a working project several times, in just 24-to-48 hours. Except normal project development isn’t a hackathon. At hackathons, you’re trapped in a building, with nothing distracting you and your team from working on one single project. Food is provided to you. You don’t have to sleep, and doing so is a sign of weakness. None of these things are true in the world that exists outside of their Soylent and coffee-ruled quarters. People often say learning to program is a marathon. But developing a short-term project isn’t quite that, either. In a marathon, you have a lot more time. It’s instead what people in the Development World call a ‘Sprint’.
So what is a ‘Sprint’ and ‘Sprint Planning’? When you Google it, you’ll find “Sprint planning is a collaborative effort involving a ScrumMaster, who facilitates the meeting, a Product Owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the Entire Agile Team, who define the work and effort necessary to meet their sprint commitment.”
The only issue here is we didn’t have a Scrum Master, or an Agile Team. We were just two college students with a couple of laptops and widescreen monitors to work with. So how could we implement a better plan, given constrained time, lack of other developers, and while also working on multiple other projects?
Well, here’s my theory. And I think it actually does stem from what I learned at hackathons. When things did work for us, they worked great. And we were still able to churn out a prototype despite time constraints and lack of sleep. Once we were able to trim the project down, getting the rest done was relatively fast. Once the deadline neared, we started operating in a hackathon mentality, where all that mattered was getting something working to show people. This concept isn’t new in programming, and it can be summed up by what developers call a skateboard:
The skateboard isn’t sexy. It doesn’t sparkle. Nor does it drive itself using cutting-edge AI. But what it does do is very important: it works. Now, in the material world, a skateboard will only ever be a skateboard. Turning it into anything else would be ridiculous, unless you have some concept for a “Back To The Future”-Type Hoverboard you’re working on. But in the world of software, what’s cool about skateboards is they can be developed into something bigger. Maybe a bike. Add an engine, and it’s a motorbike! Keep adding to it, and you have a cat. Keep going, and one day you may even have a starship! And with each iteration, you’re getting user feedback, gaining traction, and building your team. In software, very few spaceships are made from scratch. They start out as skateboards. One of the biggest social media engines of our age started out looking like this:
Not much to look at, is it? But from that, they were able to build it into the media giant it is today (for better or worse).
So I think the best way to improve is to build something that works, as soon as possible. Build a skateboard, resist the allure of the motorbike or cat. Cats and motorbikes are sexy, but they are ridiculously hard to build. They have a lot of parts, and require a fantastic knowledge of physics. But a skateboard is easy. And then you can get feedback about what kind of transportation users actually need. Despite the hurdles, we were able to build out our skateboard, and are testing it on users right now.
And while this is small, it’ll give us the chance to get a better understanding of our users, what people desire, and how to improve our project in the future. Moonshots are great, but to do that, you need a spaceship. And to build a spaceship, you first need to build a skateboard.
