leanpizza.net - tasty Agile… one slice at a time – by Olivier Lafontan

Patterns

October 6, 2010

Startups, technical and organisation debt: why does it always happen?

Tags: , ,

Over the years, I have worked with quite a few companies that started 5 to 15 years earlier and had achieved a great level of success in that time frame.

However, the anti-pattern is that it takes them that time and that success to realise the amount of debt they have accrued and that it is always a right pain to try and introduce some agile discipline at this point.

The startups I have worked all started the same way: a first level of private funding, a disruptive or new business model, an ability to execute and implement that idea fast and hit the market quickly, and finally an ability to generate working capital from the first releases so as to not have to reach out to external investors too early.

After a few years of that model, there is usually the need to get external funding in place to fuel the growth further, or the founders my decide to flip the company.

Hitting the market as early as possible and create working capital can pressure the startup to NOT LOOK carefully at the amount of technical and organisation debt they are introducing from day one in and around the solution they are building. Let’s face it, the first milestone for a startup is to effectively “test” their idea or product or service, not too invest in high quality grade release from day 1.

Now, that is the beginning of the issue for the successful startup: a few years and a few incarnations of that idea later, the successful company will find itself in a position where:

  • competitors and new entrants become more and more aggressive (since the successful company is the proof that the business model and market is worth investing in)
  • employees become complacent (who wouldn’t when the company you are working for is doing so well!)
  • the technical / human schemas are supported by a handful of historical heroes in the company

This in turn creates all sorts of issues for the company that was once a startup, among which:

  1. it is hard for everyone to realise that the company’s success might not last forever
  2. it is hard for the company to adapt its technical infrastructure
  3. it is hard for the business to implement new ideas as fast as the new entrants (at least as fast as they were when they started)
  4. it is hard to grow organically since the knowledge is contained in a key people’s head and that the learning curve for new employees is so steep (I have seen this especially on the software front, were although technologies employed might be mainstream, their historical implementation or architecture might be very left field).

There is an argument here to suggest that a method that would allow a good mitigation of these risks should be part of any good startup setup and business plan.

The point 1 above is a culture trait, usually driven by the fact that everybody needs to relax a bit and enjoy the moment when success happens. When that success sticks for a while, that relaxation becomes part of the company’s DNA, and that complacency is just “the way we are”. It takes a champion, a real threatening situation and a good dose of effort to change that feeling of invincibility.

Points 2, 3 and 4 might be mitigated by the careful application of specific discipline from the very beginning of the venture. Note that this doesn’t mean extra upfront planning and design, it often means the use from day 1 of techniques providing more simplicity, visibility and collaboration.

Agile and Lean methods will usually help a company enhance their chances to not be hit by the points mentioned above in the long run. It would take very little time for a startup company to see the benefits and payback of having done careful TDD, pair programming, Continuous Integration from day 1 and having built up a rhythm and an organisation feeding on continuous improvement feedback loops. Some of the effects will be:

  • what can be standardised is standardised at the last responsible moment, not too early and not never (will help mitigate the future infrastructure issues). Waste is removed from the system one bit at the time
  • common code ownership will be in place across the organisation, allowing for decoupled business planning and decisions to take place with less capacity constraints
  • simplicity of the product and time to market will remain a (low) constant over time through the omnipresence of high level of test coverage (UT, AT, ST) as well as Continuous Integration and automation.
  • Total Cost of Ownership will also remain low, helping the company to attract further investment or potential buyers
  • new employees can start being productive a lot faster, which is an important factor when growing or expanding

Lastly, I think there might be a blocker for a startup to actually implement Agile and Lean in their way of doing things from day 1: cost and availability.

It actually costs quite a lot to “source” people who follow this discipline. It is wrong to think that good resources come cheap, because they don’t, and there aren’t that many people available either.

My advice to startups: don’t wait too long before you introduce Agile and Lean disciplines in your organisation, knowingly and purposefully invest in it, because waiting for too long will prevent you from successfully doing it in the future.

Share and Enjoy:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks

Post to Twitter Post to Facebook

Leave a comment

RSS feed for comments on this post. TrackBack URL

You can use these XHTML tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>