How agile should your startup be?

By Danny Boice , written on December 31, 2012

From The News Desk

Speed is key to the software development cycle. Releases must come early and often, and the focus must be on high-priority development tasks. Features and bug fixes are especially important when budgets are constrained.

Development in a startup is nothing more then a race to hit your hockey stick-shaped growth curve before the cash runs dry. So the question arises -- what is the best software development methodology to follow for startups?

There are basically three primary categories when it comes to software development methodologies: Waterfall, Agile and what I call “Developer Rambo." Any other methodology is a nuance of one of the above.

Some may argue that there’s a fourth called RUP. Those people are wrong and should be mocked. But I digress. For those unfamiliar with the methodologies, a quick primer:

Waterfall -- Waterfall methodologies define requirements (in great detail) up front and then attempt to use those requirements to lock in on a set estimate of time and money to develop them, where progress flows down sequentially through the development phases (hence the name). These methodologies tend to approach building software in the same way you would approach building a house: define, design, build, test, and release. Waterfall projects attempt to set scope, budget and dates in stone.

Waterfall has lately fallen out of favor at both enterprises and startups.  It has become common belief, and rightly so, that you’re lying to yourself if you really believe that you can set scope, budget AND dates for a project. It’s also a well-known fact that many features built in a waterfall project are never actually used by end users.

Agile -- Agile methodologies involve all of the same things as Waterfall, but as the name implies, the focus is on agility, as well as adaptability. Phases are shorter -- typically a couple of weeks, and can be less strictly sequential, as Agile's modular nature allows for coding to be done simultaneously by different groups. In Agile projects the scope is always variable, and you only work on the most important tasks during your current iteration. Budget and dates are set in stone. The scope, or features that you will release, are not.

Agile is in vogue in both enterprises and startups -- especially in a permutation known as Scrum, the primary innovation of which is bringing decision-making into the feedback loop so that management is rolling apace with the project, as opposed to a traditional “command-and-control” style.

Development teams love "Agile" because, rather than spending their time doing large-scale, shot-in-the-dark estimations, they can focus on building. Product teams love it because they can intelligently validate and test feature concepts along the way, adjusting as needed. Execs love it because it allows for early-and-often release cycles. These are definitely huge potential upsides, but taking advantage of them requires as much—if not more— discipline and thought as old-school Waterfall projects.

"Developer Rambo" -- I call the third approach “Developer Rambo” because it’s chaotic, heroic, and bloody. Each developer is left to survive on their own in the jungles of Development Hell, armed with nothing more than an iron will and their stainless-steel MacBook Pro. Survive and succeed under any conditions. The ends justify the means.

In other words, “Developer Rambo” represents the total lack of a methodology; developers are just hacking away in the dark. It's risky, but it does work for some.

Which way to go?

Contrary to popular belief, both Waterfall and Agile take massive amounts of discipline, management and oversight. Even in Agile there are typically separate bodies filling the “Scrum Master” and “Product Owner” roles with duties above and beyond those of your typical developers, designs and QA testers. This is a lot for a startup to swing.

It seems clear that if your company is big enough to have the cast needed to manage a Scrum (Agile) process, than that's the way to go. But what do you do if you’re one or two developers, a CTO and some interns to do QA testing?

The startup solution

Speek does a very lightweight take on Agile. We have all the ingredients to Scrum -- huddles, user stories, a backlog, planning and grooming -- just like any good Scrum practice. However we do them in a very lightweight and quick way.

First, we do one-week iterations (aka sprints). This is typically a no-no to agile purists. Two-week sprints are considered standard. Three-week sprints are acceptable but only in special circumstances. The reasons we do one-week iterations are simple: a) We can’t go two weeks without releasing something new, and b) priorities change daily, so planning development tasks in two-week chunks would be suicidal.  We need to be able to react quickly.  What is important today probably wasn’t important two weeks ago.

A typical week at Speek

Monday: We hold a consolidated planning/grooming meeting. We do this standing up because meetings suck and people standing up tend to hurry. As the dude running product and tech, I am the one making priority calls in terms of which user stories make it into the iteration. Developers are intimately involved and ultimately size the stories and commit to get them done that week.

Tuesday, Wednesday & Thursday: Daily standups occur. This is how we identify and resolve any blockers/questions that arise during the week. We all work in the same office every day so there is a LOT of face-to-face ad hoc collaboration that occurs. Our QA tester, who is an entry-level recent college graduate, tests and accepts stories as developers complete them. He rocks (literally, he’s in a band).

Friday: We promote all code to our QA environment on Friday morning. We spend a few hours banging on the app in the QA environment -- our poor man’s version of regression testing. We’ll roll out Selenium scripts to make this more efficient someday. If we find blockers, the developers quickly fix them. By end of day we are ready to promote to production.

Saturday: Late Friday night or sometime during the day on Saturday, we promote from QA to production and do a release. The same group of us that tested in QA test in production over the weekend to make sure we didn’t just shit the bed on our live site. 

Sunday: We remind our families that we exist.

Monday: repeat.

The bottom line: You need to find what works for you. Try a few different riffs on Agile or “Developer Rambo” and remain open-minded.  When it comes to startups, there really is no one-size-fits-all solution.

[Image courtesy Heart Industry]