Saturday 28 February 2015

Scrum Works Better in Startups

Inspired by this article, I've been thinking about how agile works better in startups than in mature companies.  The article in question argues that Kanban is often more appropriate for startups due to the time-to-market imperative and the rapid pace of change, and I'm not disagreeing with that because a) she makes a great point, and b) I'm not going to argue with an agile maven like Abby Fichtner. 

Rather, it occurs to me that the posts I've written previously suggest that scrum is difficult to implement in practise because of the unicorn at the heart of scrum, which tends to lead towards an inevitable Water-Scrum-Fall situation.  This could imply that I think scrum doesn't work.  This is not true.  Scrum is a great methodology and although its application is hindered by the lack of multi-functional teams, that doesn't mean that it can't still be implemented well and have many benefits.

However, my experience comes
mainly from working with mature products and teams, or new products and teams within mature companies.  The larger and more mature a company gets, the more specialists they employ.  No tech startup hires an agile coach as one of their first employees; it's normally 2 or 3 coders with an idea and easy access to deliverable fast food.  Agile coaches come after another developer, an accountant, a saleswoman, a marketing guy, a tester, another couple of developers, and about 50 other people, because that's the point when the company stops being naturally agile and starts needing help to understand and proceduralise the things that make them good at what they do.

In a more mature company that's got hundreds or thousands of staff you'll find increasing levels of specialisation.  In the technical writing team you might have editors, sub-editors, API specialists, tools experts, learning and education experts, and so on, on top of a pool of staff writers who actually document the output from development.  And then there's the non-technical writers who provide marketing copy, sales brochures, company reports, blog posts, social media content, and all other manner of written communications.  In a startup, the founders will do all of that as and when necessary, and as they hire staff the marketing guy will produce the marketing copy, the saleswoman will put together the sales brochure and the developers will provide some release notes or instructions on installing the product.  After that, as the company grows further, someone in development will gradually start to take responsibility for documentation and eventually become the technical writer, or the company will hire someone specifically to write it.  At that point, scrum starts to become more difficult.

In a startup, generalists are highly valued because there are many jobs to do and not many people to do them.  The founders and early employees have to do everything from development to sales to documentation to marketing to testing to paying the wages and they normally lack proscriptive standards for these things.  Therefore, an agile development methodology like scrum or Kanban is ideal: it allows them maximum agility and they are already a fully multi-functional team where the emphasis is on quick, iterative delivery.  As a company grows though, employees become more specialised to increase efficiency and quality.  This is an economy of scale that basically turns any suitably large company into a form of production line.  Processes, procedures and standards provide not only the structure of the company which analysts can constantly study for new ways to increase efficiency (read: profits), but also the conceptual conveyor belt along which the product passes from conception through delivery and implementation to maintenance and support.

But scrum is the antithesis of this production line ethos with its proscriptive standards and linear flow.  Scrum suggests, nay, demands a multi-functional approach to production within the scrum team, and that cannot happen if the scrum team is made up of specialists.
 

The more specialised the roles in your company are, the less effective scrum will be

This highlights an inherent tension that might help explain why so many companies end up implementing some version of Water-Scrum-Fall and not getting the results they expected.  Specialism - division of labour - is a clearly defined economic tool to help companies scale up their production to make it more efficient and, ultimately, increase profits.  This is one of the reasons why Waterfall is considered to be an efficient model.  Scrum is a methodology that demands generalists.  Therefore, whilst scrum can be more efficient and produce higher-quality deliverables in a small team, the staff needed for it are at odds with the staff needed for the traditional division-of-labour, process-driven methodologies.  So large companies have specialists who work in a (conceptually) linear process, but if the company tries to implement scrum they need to employ generalists that don't fit with the perceived conception of efficiency. 

In a startup though, specialisms are an anathema, and the entire company - which might be as small as 1 person - is composed of generalists who are agile by default.  Agile is not so much the right methodology for a startup to use, it's the only methodology that can be used.  Really, agile development as a methodology is the re-creation and formalisation of a tech startup mentality for larger companies, and larger companies have moved away from the generalised skill set needed to fuel that mentality in favour of a division-of-labour efficiency.  Is agile trying to recapture a mentality that's inevitably lost in the paradigm shift to being a "proper" company?  Is it possible for a large company to be agile in this way?  I'm not sure it is.

I'd be interested in hearing from anyone that seen a startup move from being a small agile operation to a larger company with increasing specialisation.  Did
your company keep itself agile?  How did it do it?  Were generalists still valued as highly?  Thoughts and experiences are welcome in the comments.....

No comments:

Post a Comment

Note: only a member of this blog may post a comment.