I started writing another piece on more economic and agile/software development but it got too long, so right now, an aside...

Back in 1968, Peter Drucker wrote:

"Large organizations cannot be versatile. A large organization is effective through its mass rather than through its agility."

Last week I presented "Agile for Start-ups" here in London for the third time. Each time I've given this talk it has been largely rewritten - this time I think I've got it nailed. Part of the problem is I tend towards the view that "Start-Ups don't need Agile," or rather they do, but agile comes naturally and if it doesn't then the start-up is finished. It's later when the company grows a bit that it needs Agile. And notice here, I'm differentiating between agile - the state of agility - and Agile as a recognized method.

New, energetic, start-ups are naturally agile, they don't need an Agile method. As they grow there may well come a time when an Agile method, specific Agile tools, are useful in helping the start-up keep its agility. Am I splitting hairs?

For a small start-up, agile should be a natural advantage. On day one, when there are two people in a room making the startup it isn't a question of what process they are going to follow. At the very beginning, a start-up lives or dies by two things: passion and a great idea. In the beginning, it should be pure energy.

In many ways, the ideas behind Agile are an effort to help companies maintain this natural agility as they grow. Big, established, companies who have lost any natural agility seem to resemble middle-aged men trying to recapture a lost youth.

So when does a start-up need to get Agile? - a more formal way of keeping fit, as it were.

Not all day-1 start-ups are pure passion, ideas, and energy. Some need to find their thing. They need an approach to finding their reason for being. Agile can provide that structure.

And start-ups which are taking a Lean Start-Up approach also need a method. They may have passion and energy in the room but the lean startup market, test-driven approach demands discipline and iteration. Lean Start-Up demands you kill your children if nobody wants them.

When I look at Lean Start-Up, I see an engineer's solution to the problem of "What product should our company build to be successful?" The engineered solution is to try something, see what happens, learn from the result, maybe build on that try or perhaps change (pivot) and repeat.

In both these cases, a start-up needs to be able to Iterate: Try something, see what happens, learn from it, and go round the loop again.

You can generalize these two cases to one: Product Discovery through repeated experimentation.

That requires a discipline and it requires a method - even if the method is informal and subject to frequent change. It can be supplemented with traditional research and innovation approaches.

The next time a start-up can benefit from Agile (as in a method) is as it grows: as it becomes a "scale-up" rather than a start-up. This might be when you grow from two to three, or from 10 to 13, or even 100 to 130, but, at some point, the sheer energy driven nature of a start-up needs to give way to more structure.

This probably coincides with success - the company has grown and survived long enough to grow. Someone, be they customers or investors, is paying the company money. It is no longer enough to rely on chance.

The problem now is that introducing a more defined method risks damaging the culture and way the start-up is working - which is successful right now. So now the risk of change is very real, there is something to lose!

Just as the company can think about the future it needs to risk that future. But no change is also risky, with growth the processes and practices which brought initial success may not be sustainable in a larger setting.

This is the point where I've seen many companies go wrong. They go wrong because they decide to become a "proper company" and do things properly. Which probably means adding some project managers and trying to be like so many other companies. They give up their natural agility.

Innovation in process goes out the window and attempts to turn innovative work into planned projects are doomed. Show me the project plan with a date for "Innovation happens here" or "Joe gets great idea in morning shower" or "Sam bumps into really big contact."

It is at this point that I think Agile methods really can help. But those approaches need to be introduced carefully, working with the grain of the organization. Some eggs are bound to be broken but this shouldn't be a scorched earth policy.

Start-ups and scale-ups need to approach their products and Agile introduction as they do their business growth: organically. Grow it carefully, don't force feed it, don't impose it - inspire the staff to change and let them take the initiative.

It is much easier to do this while the team is small. Changing the way one team of five works is far easier than changing the way four teams of eight work. It's also cheaper because once one team is working well it can grow and split - amoeba-like - and later teams will be born with good habits.

Unfortunately, companies, especially smaller ones, put a lot of faith in hiring more people to increase their output and thereby postpone the day when the team adopts a more productive and predictable style of working.

This might be because they believe new hires will have the same work ethic and productivity as the early hires: they probably won't if only because they have more to learn (people, code, processes, domain) when they start.

Or it might be because the firm doesn't want to lose productivity while they change: in my experience, when the change is done right, short-term productivity doesn't fall much and quickly starts growing.

It might just be money saving: why pay for training and advice today? - yet such advice isn't expensive in the scheme of things, certainly delaying a new hire by a couple of months should cover it.

Or it might just be the old, "We haven't got time to change" problem. Which always reminds me of a joke Nancy Van Schooenderwoert once told me:

"A police officer sees a boy with a bicycle walking along the road at 10am.
Police: Excuse me young sir, shouldn't you be in school?
Boy: Yes officer, I'm rushing there right now.
Police: Wouldn't it be faster to ride your bike down the hill?
Boy: Yes officer, but I don't have the time to get on the bike."