DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. When Does a Start-Up Need Agile?

When Does a Start-Up Need Agile?

By their nature, start-ups are agile and energy driven. It's only as companies grow that an Agile framework needs to be considered and put into place.

Allan Kelly user avatar by
Allan Kelly
CORE ·
Dec. 08, 17 · Opinion
Like (1)
Save
Tweet
Share
6.33K Views

Join the DZone community and get the full member experience.

Join For Free

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."

agile

Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Deploying Java Serverless Functions as AWS Lambda
  • Building a Scalable Search Architecture
  • Java Development Trends 2023
  • Memory Debugging: A Deep Level of Insight

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: