Scrum for Startups - does it work?
I am currently the Agile Coach/Scrum Master/Project Guru (that last, totally unpretentious title was dreamed up by Peter, one of the founders, but it looks cool at the bottom of an email) at a startup, Crunding, which makes mobile apps for end-users. This is not my first job at a startup, in fact this company is a lot more 'established' than anywhere I have worked in the last few years.
When looking at Scrum and Agile, one of the things that strikes me is that the loudest advocates of Agile techniques seem to be working at the least Agile organisations, like banks and in government. That is of course a good thing: top-down organisations have a lot that they can learn from mindsets that promote innovation.
But the startup crowd is very quiet when it comes to getting organised. If you have a young product, are not stuck in a rut and indeed have no solidified management yet - the eyes are not yet turned inwards and there is perhaps less to talk about. However, some startups do innovate in the way they are run, even if very few of them talk about it.
Here is my first instalment on Scrum for Startups.
The startup world is not completely silent about how to get organised, as the success of the Lean Startup shows. And the use of Scrum and other Agile techniques is an oft-discussed topic, even if it is not always a good fit.
She therefore advocates the use of another Agile framework - Kanban. Now I really don't want to bash Kanban and I know Abby's post is very old, but this discussion comes up fairly often. Scrum is simply not good for many situations. This said, neither is Kanban. In fact - no framework or method is suitable for all situations. At Crunding, we use Kanban for Operations type work like support and server maintenance and Scrum (and a lot of other Agile tools) for our development teams. The business team follows the development release cycle but organises itself using Kanban or Scrumban. Ideation works with Deep Scrum and Lean Startup and ad-hoc teams do Design Studio's when we think it will help. Basically it is a well organised chaos.
As a startup you don't want to get bogged down in procedures, you don't have the money for a large management structure or motivating workers with big pay-rises. Even if you are funded to the eyebrows, you still want to get out a product quickly.
Scrum does not work very well for what Kenneth Rubin calls 'interrupt-driven' work. This is because, in Scrum, we estimate what we will do at the beginning of each time-boxed sprint. If this changes in the middle, we either pointlessly finish the sprint, blindly doing what we know is not wanted or we have to replan and reorder what needs to be done and see what we can do. Many interruptions mean many replanning sessions and therefore wasting time.
But how 'interrupt-driven' is work at a startup really? If you are constantly having to react to the world and a one- to four-week timeframe is too long to keep working in one direction, will you be able to get anything done at all? Don't confuse being Agile with being disorganized. If you really do need to react that quickly (like perhaps a helpdesk or an emergency responder should), use Kanban instead.
A startup's work is often less planable than that of an established company, simply because of the nature of the field of work - making new stuff. This however does not mean that the work is complicated, nor that it is more prone to interruption from the outside. If you want to get a project out quickly, whilst it also being built to the exact quality and needs you have, you should be looking at Scrum as your framework.
 |
| Photo: Guian Bolisay |
When looking at Scrum and Agile, one of the things that strikes me is that the loudest advocates of Agile techniques seem to be working at the least Agile organisations, like banks and in government. That is of course a good thing: top-down organisations have a lot that they can learn from mindsets that promote innovation.
But the startup crowd is very quiet when it comes to getting organised. If you have a young product, are not stuck in a rut and indeed have no solidified management yet - the eyes are not yet turned inwards and there is perhaps less to talk about. However, some startups do innovate in the way they are run, even if very few of them talk about it.
Here is my first instalment on Scrum for Startups.
The startup world is not completely silent about how to get organised, as the success of the Lean Startup shows. And the use of Scrum and other Agile techniques is an oft-discussed topic, even if it is not always a good fit.
Is Scrum right for my startup?
As blogger and Agile Coach Abby Fitchner points out, rather simplistically, Scrum may not be the tool you need as a startup. She advocates using Kanban instead because Scrum's time boxes would slow you down - a two week sprint takes too much time and the world of technology simply moves too fast.She therefore advocates the use of another Agile framework - Kanban. Now I really don't want to bash Kanban and I know Abby's post is very old, but this discussion comes up fairly often. Scrum is simply not good for many situations. This said, neither is Kanban. In fact - no framework or method is suitable for all situations. At Crunding, we use Kanban for Operations type work like support and server maintenance and Scrum (and a lot of other Agile tools) for our development teams. The business team follows the development release cycle but organises itself using Kanban or Scrumban. Ideation works with Deep Scrum and Lean Startup and ad-hoc teams do Design Studio's when we think it will help. Basically it is a well organised chaos.
Is Agile right for my startup?
Here the answer is much easier: yes. Kanban, XP, Scrum, Lean, FDD and all of the other Agile methods and frameworks are far superior to 'waterfall'. Because large and/or old organisations almost automatically have a 20th century command-and-control management structure, they start with a handicap. A startup can pre-empt this before getting into bad habits; before they do, startups are 'naively agile'.As a startup you don't want to get bogged down in procedures, you don't have the money for a large management structure or motivating workers with big pay-rises. Even if you are funded to the eyebrows, you still want to get out a product quickly.
When Scrum IS right
Scrum is for complex, rather than complicated projects. That means that if your project involves a lot of different features, which interact in unpredictable ways, you should be looking at Scrum. If it just contains a lot of moving parts but they react to each other predictably or in a way that a bit of study would make you understand, maybe look for something else. If you are making a one-off car, use Scrum, if you are making a series of cars in a factory, use something else.Scrum does not work very well for what Kenneth Rubin calls 'interrupt-driven' work. This is because, in Scrum, we estimate what we will do at the beginning of each time-boxed sprint. If this changes in the middle, we either pointlessly finish the sprint, blindly doing what we know is not wanted or we have to replan and reorder what needs to be done and see what we can do. Many interruptions mean many replanning sessions and therefore wasting time.
But how 'interrupt-driven' is work at a startup really? If you are constantly having to react to the world and a one- to four-week timeframe is too long to keep working in one direction, will you be able to get anything done at all? Don't confuse being Agile with being disorganized. If you really do need to react that quickly (like perhaps a helpdesk or an emergency responder should), use Kanban instead.
A startup's work is often less planable than that of an established company, simply because of the nature of the field of work - making new stuff. This however does not mean that the work is complicated, nor that it is more prone to interruption from the outside. If you want to get a project out quickly, whilst it also being built to the exact quality and needs you have, you should be looking at Scrum as your framework.
Experiences
Scrum and startups are a great combination in my experience, but just like any established organisation, the rest of the company needs to be ready for it.- Get a lot of support from all areas of the company, Agile everything.
- Really empower the teams to be self-managing.
- Be really, glaringly transparent - have everything out in the open - it will prevent sabotage.
- Preserve the naive agility that is there
- Enjoy it, make sure people are happy a lot of the time.
- Learn some things from how successful companies are organized, then ignore the rest
Comments
Post a Comment