Is Agile too inefficient for start-ups?

Is Agile too inefficient for cash-strapped start-ups?

To answer that, let's look at how an Agilist (with a strong Extreme Programming flavour) would think about preserving cash.

Fewer people means lower burn rate
Although the trendier terms are "T-shaped people" or "generalising specialists", the original discussions were more aggressive about having people who could do everything.

"A programmer should be able to find a bug, market an application, refactor a spike, lead a team, architect an application, hack a kernel, schedule a project, build a database, route a network, give a reference, implement UserStories, analyze UserStories, work in a team, work alone, use patterns, innovate, write documentation, have a RealLife, create a cool website, email efficiently, resign gracefully, AdmitIgnorance, and keep on learning.  Specialization is for recruiters. " 

Peter Merel, Specialization Is for Insects

I tend to use the following images when I do the introduction to Agile thing:

Fewer people means lower burn rate.  Simple enough.

Do less

"Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters? … Listen, Test, Code, Refactor. That's all there is to software. Anyone who tells you different is selling something." 

Kent Beck, from the original version of the Extreme Programming page on c2.com

Startups are too damned hard to spend time on things that don't matter.  So, starting over from scratch, what are we absolutely certain matters?  Well, at the end of the day, a startup is a temporary institution whose purpose is to discover a repeatable process that:

1. Creates and defines something of value...
2. ... that other people want or need...
3. ... at a price they are willing to pay...
4. ...in a way that satisfies the customer's needs and expectations...
5. ...so that the business brings in enough profit to make it worthwhile for the owners to continue operation.

Anything else is wasting cash you don't have.

With acknowledgements to Josh Kaufmann.

Do less of what doesn't matter so you have cash to do more of what does matter.  Simple enough.

Don't spend money on things you may not need

"Make it work, make it right, make it fast" 

Kent Beck 

The Agile approach to design has always been prioritised on whether the result worked, then whether the result was "right" (No duplication, expressive, minimal), and only then looking at performance considerations... and even then only to the extent that it was needed now.

You Ain't Gonna Need It was about creating a culture of simplicity (you must justify building more than you need to), which tends to preserve cash, versus a culture of anticipation (you must justify why you're not building something that handles every imaginable scenario), which tends to burn cash as if it magically falls from the heavens.

I'm not sure at what point building excessively scalable solutions to the wrong problem became associated with Agile engineering practice.

Don't spend money speculatively on things you may not need.  Simple enough.

Release (aka go cash flow positive) early

The classic Agile model is to incrementally release subsets of an overall product / vision rather than all at once to dramatically reduce time-to-market and therefore time-to-profit.  In essence, the strategy is to go cash flow positive early.

Release faster and make money faster.  Simple enough.

You keep saying Agile but I don't think it means what you think it means...
Arguing that particular roles or rituals are required for Agile, which therefore makes Agile inefficient for startups, even though those roles or rituals don't align with what an Agile thought process would produce for a startup context, is reflective of both a watered down and cargo-cult understanding of Agile.

Questionable ways to preserve cash
But isn't Agile still bunk when it comes to start-ups?

After all, in start-ups in order to preserve cash you need to...

Work crazy hours... even though we know that it's less productive (aka produces less output given the same investment) within a relatively short period of time.

Just hack something rather than pair or test... since in the start-up world, typing has somehow become the constraint in programming, not thinking... and since start-ups are unlike every other software context where low internal quality slows things down much more quickly than most people realise.

Build it first and check with potential customers later... since in the start-up world, you can't afford the effort required to get concrete feedback on whether anyone wants what you're building.

What's interesting is that the same questionable ideas exist in the enterprise setting.

In the enterprise, it is reflective of lazy, undisciplined thinking and behaviour.  In the enterprise, it is theatre to justify failure.   And perhaps, in the enterprise, it is theatre to convince people with money to continue to fund a project.

But I'm sure that's not what is happening with start-ups.

But I really am cash-strapped...
But still, "cash-strapped" really means cash-strapped so even Agile tactics might not be enough.  What else could you do?

Find alternative ways to get cash (aka "be scrappy").  This can be consulting or even selling cereal.

Sell the solution to the problem first, build something after (aka the Concierge MVP).

Find a way to have an interim offering that segments an existing market to pay for your new market, new product game changer OR when you have no money, stop trying to create an unproven market with unproven technology