Scrum for Startups - Scaling Scrum? or just a lot of Scrum?

Yesterday I attended Scrum Day Europe, which had the theme 'Scaling Scrum'.  Perhaps predictably, the only one to consider the case: 'natural growth' was Gunther Verheyen.  Everyone who spoke after him was actually talking about how to impose/implement Scrum when you already have lots of people.

Startups have the luxury that they can think about scaling before having to do it and can make/choose a framework that they can settle- as opposed to get-crammed-into.

This topic has interested me since, as a budding Scrum Master, I heard about the Scrum implementation at a Dutch bank, ING, where they had just implemented Scrum in 135 teams.  It all sounded very exciting, a massive giant of an organisation that had decided to 'become Agile'.   Later, when formalising my Scrum knowledge on a Scrum Master course, I met more ING folk, but this time they seemed a lot less enthusiastic.  Not because of Scrum, but because the organisation around them had decided to adopt 'Architects' and 'Q&A teams' - not particularly Agile practices.  The management layers were not adapting to the new situation and I understand that this is still a problem.

How, at a startup, should you start scaling and how much, if anything, can you learn from 'old' organisation?

Naive Agility vs Imposed Rigidity

You would think that a startup is lean and mean, that agility is inherent in an organisation that has not had time to go rusty.  I can tell you that that is far from the truth.  Especially when you have to deal with banks or external financiers, things quickly get far from Agile.  But I have also come across founders wanting to think up everything in advance for superficially good reasons like hardening their vision or to get developers to stick to the plan or delivering what they promise.  Until 'lean startup' the advice was always 'first, write a business plan'.

These practices mean that even a startup has some bad habits by the time they are together enough to consider growing.  Even completely newly-founded startups with a large budget often inherit baggage from managers that get in the way with growth.  I interviewed for a job last winter at a startup that was being created to house the marketing department of a large retailer.  They were three months old but they already had decision-making lag because their board of directors wanted to command-and-control all of the processes.  They seemed to be breaking records for turning something new, fresh and agile into an oil tanker.

So, is it hopeless? Are we just as handicapped in startups as if we were an enterprise scale organisation?  Luckily there is an important difference in where a startup is, compared to the legacy problems in most enterprises - our product is still young.  That really is the key - if your product backlog can be built up without too much dependencies, your teams can operate independently, thereby not requiring too much organisational overhead.  Many of those familiar with XP will know the mnemonic 'INVEST' for defining good user stories - the 'Independence' of items in your product backlog dictates how self-organising your teams can be.

"One comes to the conclusion that this idea of scaling scrum teams to a larger endeavour is dependent on your ability to reduce the dependencies between the teams."  - Ken Schwaber April 3rd 2015

There are currently five scaling methods/frameworks that I know of (the first three are summarised here).  They are listed in order of my perception of their Agility, most rigid first.  

• SAFe - Scaled Agile Framework
• DAD - Disciplined Agile Development
• LeSS - Large Scale Scrum
• Scrum at Scale - Scrum Inc's Scaling Framework
• SPS/Nexus - Scaling Professional Scrum (recent addition by Ken Schwaber)

The 2nd of July saw Scrum Day Europe in Amsterdam. A disclaimer: this day was organised by Prowareness, a consultancy that earns its money by training and certifying Scrum professionals. They are heavily invested in enterprise scaling of Agile as their customers are exclusively large. That said, I did learn some new things about scaling Scrum but the attention was heavily skewed to large enterprises.

Usually, scaling Scrum means - we go to an already large company and we implement Scrum.  Because the company is already large and has many employees that it cannot fire and already has products that it knows and runs, the need is for a matrix that fits the existing structure.  The main complaint seems to stem from a lack of commitment to Scrum - in the business as opposed to the developers.  The business already has a set of behaviours and expectations and wants to better the process of development without having to change these practices.

Real Scrum is impossible to scale.

Much like a city is not a scaled-up village, an enterprise IT department is not a scaled-up scrum team. Scalability of human relationships is severely limited by the number of interactions someone can have and the number of people one can know well.  In a practiced Scrum team, people know each other well and the members of the team can easily interact with each other without it having a serious impact on their productive time.  In Scrum we don't want more than nine people in a team and prefer about five team members for this very reason.

Which is probably the reason that Nexus - in my opinion the most 'vanilla' of the Scrum scaling techniques - scales to a max of 9 teams.  It is a Scrum team for Scrum teams.  It does carry some overhead - a Nexus team has to continually monitor and regulate integration of the teams' outputs.  It is probably what I will be choosing if we need to integrate.

Hopefully that will never be necessary.  If your product backlog items carry almost no dependencies, there is no real reason for 'scaling' at all.  In most cases it may be better to solve your problem by keeping your product small, clean and modular.

Lessons from Open Source

Open Source projects like Linux have managed to swim against the tide in terms of being Agile and still scaling.  The thing that these projects have gotten right is that lack of management has meant that they have been forced to self-organize.  And to be honest, it is a Darwinian process - there are scores of abandoned projects for every Ubuntu, Apache and Firefox. 

There are of course a few other things that Open Source projects have gotten wrong.  The major one is earning model - it is still very hard for a large number of people to earn their living in Open Source. Agile solves this problem by either employing the entire team or with very Agile contracts and compromising a little on the self-management of teams (for example, at a Swiss Post Scrum implementation they had Agile contracts but teams could not 'pull' work items off the backlog - instead getting delegated items from the Product Owners).

Then there is specialisation - something that Scrum also has trouble with.  What to do with people who are specialised in other fields that do not contribute continually to the product like marketeers or UX designers? Open Source has no use for them, in Scrum we have to spoon them in somehow.  We prefer it when people are good at other things too, so they can contribute evenly to a product.  But that can lead to high-quality software that is horrendously ugly to look at.

But if there is just one thing that growing startups can learn from Open Source, it is to have small, modular products that have little to no interdependencies.  That way teams can develop the product independently from each other so that no central organisation is necessary.  And when integration is needed - make an open standard for sharing between the products.  If a standard does not quite fit - one team can fork a product to suit their needs, whilst the original builder can merge this later on.  If you can avoid it: don't scale, just grow.