We’ve put a lot into Ramps, and it shows. Our contributions have exceeded 850 hours of work over a duration of 18 weeks. Comprised of 347 design assets and 43,284 lines of code, we wanted to make our first game the absolute best experience possible and neither of us were willing to compromise on much (in fact, we accomplished nearly everything we set out to do!) Tyler and I have both participated in collaborations in the past, some successful and some that haven’t quite got off the ground. So what made Ramps different? Naturally, we put our heart into it and were incredibly pumped to make it happen, but doesn’t every collaboration start out that way?

In my opinion, the biggest contributor to us being able to ship Ramps (which is easily the biggest side-project-turned-Company I’ve ever been apart of) was our investment and buy-in to our process. Though our process developed organically, in hindsight, it wasn’t a pre-conceived effort. Tyler and I have both worked in the tech industry for a long time, and I gravitated towards an agile methodology which is something I’ve grown accustomed to working with during product development for my daytime employer.

Because we were so focused on the product, we never really sat down face-to-face and said, “Okay, let’s put a process in-place and hold each other accountable to it.” I’ve never worked for a full-fledged startup (until now!), but I’d like to think we adopted an approach that many other tech startups take. What worked great for us was to adapt components of a process as they become necessary.

Ramps started out as more of a feasibility exploration and evolved organically. We never really said, “Hey, let’s go make this game!” Tyler and I had chatted about doing a port of his original Flash game, and I spent some time exploring (see also: dinking around) with cocos2d, which is a popular open-source 2D iOS game development platform, and box2d, an immensely popular, open-source, cross-platform physics engine.

Tyler mentioned to me recently that at one point our work, “…stopped existing as merely a tech demo and really became a game.” Once we reached that epiphany, everything started to kick into high-gear. We started gaining momentum, and with that we utilized a number of tools to help us manage the gigantic flow of tasks, bugs, assets and various forms of communication that flew fast and furiously. In hindsight (and foresight.. there’s still a lot more of Ramps left to build!), we adopted a light-weight process that I believe was a hybrid of Scrum and Lean.

The most prominent elements of Scrum we used were daily communication and a consistent feedback loop. Tyler and I chatted online and exchanged e-mails almost every day for the last five months. At the end of each day, we’d give our daily update via e-mail. We’d provide each other code or assets as they were completed, and give each other feedback as soon as we could. If we ran into roadblocks, we’d resolve them immediately by making a joint decision.

Most of our process really embodied the seven principles of Lean, a flavor of Agile.

Eliminate Waste

Don’t make stuff for the sake of making it! From a development perspective, I tried to only create layers of abstraction if I knew for a fact that they would be repeated. As I discovered patterns and found myself in a repetitive rut, I’d re-factor code. Early on, I actually spent an entire weekend (20+ hours) just re-factoring because I saw a more efficient way of working with box2d that I knew we would benefit from long-term. It was nice to really get this right, though because this is the first game I’ve ever developed, I also made a lot of mistakes that I can learn from the next time I use cocos2d and box2d for a new game.

Other elements of eliminating waste we used included quick-turnaround communication and maintaining clear requirements. I felt our successes here pointed back to establishing momentum and being engaged every day. Since we were both thinking and talking about Ramps all the time, this came pretty naturally for us. If we weren’t regularly wired-in, it could have hurt the project.

Amplify Learning

To me, this principle just meant that we needed to always having working code. I fixed bugs early and often, and always had something demo-ready on my iPhone. I treated crashes as show-stoppers. I would literally stop everything I was doing and focus on fixing a crash once it was discovered. This way, Tyler and I were both always playing Ramps, and if something wasn’t a good fit, we could change it immediately to improve the experience.

Decide as Late as Possible

This is the principle of lean I agree with the least, as decisions often go hand-in-hand with trial and error. We were very organized on when we made decisions, in that we’d start the process of making a decision while anticipating how much time we would need to make that decision. For example, we started engaging with Essa, who wrote the super killer awesome score for Ramps, about two months before we launched. This worked out great, as it gave him plenty of time to be creative and produce, but it also gave us enough time to provide feedback and iterate.

Deliver as fast as possible

Really, every night was a delivery for us. We set a target date early-on (Christmas), and went for it (and we made it!!). Instead of worrying about the big picture and over-managing the project, we tackled the project in milestones. I would work on developing a feature, a world, or a set of physics objects. Tyler would focus on designing a character or a scene. As Tyler completed designs, I would implement them. We added a lower-level of project management about six-weeks before launch to make sure we were prioritizing work items in order to hit our target date. We also made sure that we gave ourselves enough time between each milestone (alpha, beta, app submission, etc). Often, our communication mechanism for project management was informal e-mails, but we’d tweak target dates on-the-fly and we both always knew where the project was at.

Empower the Team

I am by no means a designer, but I know when something looks cool and when something looks off. Likewise, Tyler is not a Developer (with a capital D, as he puts it), but he has an eye for what feels right in a game and has plenty of technical expertise to think like a (D)eveloper. That said, in our process there were no stupid questions, no bad feedback, and no impossible ideas (some of them are just really hard/time consuming!). We both own this product, and while we had some definite high and low points, the ownership of making it a great product was on both of us. Keeping cool and remaining optimistic was essential!

Build Integrity In

At first glance, this might seem like Lean is referring to ethical integrity, but really it means the perceived integrity of the system by the customer. As long as the player has a good experience, and that all of the moving parts move well together, then the product has good integrity. To us, this meant that we were putting the customer first and that the experience they interact with is, “solid.” It meant that we wanted you to get lost playing the game, and minimize the number of times you say, “Hmm.. that seems weird.” Seeing as I’m writing this two days before we ship 1.0 (edit: Yes, I spent an insane amount of time on this post), I’m naturally a little nervous about this. But, as Matt Mullenweg says, “If you’re not embarrassed when you ship your first version you waited too long.”

We did a week of beta testing with about 12 people, and fixed over 50 “weird” things people observed (and a couple of show-stoppers), so we feel pretty good about this one. We’ll be fixing more “weird” things as we keep discovering them, as well.

See the whole

Like the Empower the Team principle, this one is really about owning the product. I don’t usually like to sub-contract work unless I have to, and when I do, I’m the most receptive to people that are extremely enthusiastic. We only subcontracted one part of Ramps (the music), and I don’t think we could have found a better fit with Essa. We found him at 8bc.org (Eight-bit Collective), and we were both immediately excited by his work. He only had two tracks posted on the site, but his musical style reminded us both of a classic 16-bit game we both grew up loving.

Ultimately, relationships and the team dynamic truly shape a product. For Tyler and I, and our work with Essa, we were able to consistently portray the experience we wanted to create, and I think that enabled each of us to make key decisions independently and then solicit feedback rather than waiting for a group decision before executing. Maybe that’s why so many people compare Ramps to Sonic the Hedgehog. All three of us grew up loving those games.

Communication is a huge bottleneck for any project, and while we still needed a ton of it for Ramps (and we handled it well), being engaged and iterating often helped strengthen our individual intuition to help us do what’s right for the product.