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.  

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.

Comments

  1. Good article Dennis. A couple of links to help your readers to dive deeper on the scaling approaches:
    https://www.scrum.org/Resources/What-is-Scaled-Scrum
    http://Less.works
    http://Scumcrazy.com/scaling
    http://www.agilescaling.org/

    ReplyDelete
  2. Thanks for your well thought through analysis. I was there too, partially as a Professional Scrum Trainer with Scrum.org and partially for my own learning, and I think I share your analysis that a lot of the topics were around "re-scaling" or "re-organising" a large scale project or product and applying Scrum to it. Either using scrum to do it or some other way.

    There were a few other topics, the talk on Scaling Interaction from a fellow PST, that did not really go into scaling practices, but highlighted the importance of open communication and that working with more people requires thought to how to communicate between these groups and individuals.

    The nexus tries, even for large organisations, to use the patterns you describe, small products, independent features or stories, internal open source, shared ownership and the use of architectural and coding practices that allow high frequency delivery to a production environment (single line development, automation, feature switches, dependency injection, configuration as code etc) to allow the organisation around a product to scale. Even with small independent teams each growing on their own, even startups may find themselves in situations where a core product or an integration effort may require too many people to fit a scrum team. In such cases scaling practices will help. It may even be required in order to deliver at the speed required to make a profit, enter a market or beat a competitor. Unfortunately not every startup can leverage the public to provide free patches, features an fixes, so you'll have to make do with fewer people to deliver results, sometimes this means that they need to work closely together, integrate continuously and, for no better word for it, scale.

    For completeness, there is a 5th scaling system, Scrum at Scale from Scrum Inc (http://www.scruminc.com/scrum-incs-scrum-at-scale-framework/) that, like Nexus and Less are closer to the definition of scrum and agile than DaD and SAFe. If looking for practices, patterns, ideas, I'd start there.

    Though, having passed my SAFe certification, I can say that even that framework has a large library of patterns and practices behind it, and I've found a number of them valuable.

    As long as you remember that when you reach the point that you've grown into shit or are trying to scale shit, then stop. Growing and scaling shit only gives you more of it. Step back, slow down, fix the issues you're facing and try to grow again.

    Thank you for your valuable feedback. I'd love to do a talk next year that's closer to your line of thought.

    Jesse Houwing
    Professional Scrum Trainer for Xpirit

    ReplyDelete
    Replies
    1. Hi Jesse,
      Thank you for your comments, I will add Scrum Inc's Scrum At Scale framework in my list.

      It would be dishonest of me to say that there were only topics on 'Enterprise Scrum' at Scrum Day Europe, I attended the 'Scaling Interaction' workshop and that was definitely a good starting point for those thinking about scaling for startups.

      Nexus looks like our candidate for now but in our particular case we may need a 'switchable' solution where we assemble and disband the integration roles and artefacts as needed. Some of our product backlog needs integration, a lot of it is independent. And maybe I'll repress my aversion for formal learning for long enough to sit through a Nexus course ;-).

      Would love it if there were more attention for 'growth' scaling, next to the 're-scaling/re-organising' that pays most of our bills. I'm sure if you suggest it as a topic you'll be able to fill a room - at least with one attendee anyway :-).

      Delete
  3. PS: Your comment section seems to be broken, my Blogger and Google ID don't work due to the fact that a whole bunch of cookies aren't accepted by my browser (Chrome) by default. Unblocking Blogger and Google cookies fixed it. Should be fixable, as my own blogger blog doesn't suffer from this.

    ReplyDelete
    Replies
    1. RE the comments. Due to a lot of Spam, I have had to revert to 'moderated' posting, which is why your comments only showed up later.

      Delete

Post a Comment

Popular posts from this blog

Finding your Product Goal

Agile after Corona