0

I am implementing Scrum throughout (from business development to engineering to marketing) my six-person organization.

My company consists of three engineers and three Business Development personnel.

As a startup, we have many (25+) simultaneous projects (e.g. close deals, create new marketing material, implement new features, etc...).

Does anyone have any best practices on how to implement and organize Scrum in such a "multifaceted" environment?

Everything I've read so far seems to be restrained to teams that have a single cohesive objective. Any ideas?

  • Have you considered a Kanban approach? Scrum tends to be more product focused. – Barnaby Golden Apr 4 '18 at 10:28
  • 2
    Has your reading included the authoritative document, The Scrum Guide, by the creators of the framework? – Alan Larimer Apr 4 '18 at 11:56
  • The things you're listing are recurring activities, not "projects." While Scrum can be adapted to operations, it's not really a natural fit. – Todd A. Jacobs Apr 18 '18 at 15:11
  • Let’s start with what problem you think Scrum will solve for you. – RubberDuck Apr 19 '18 at 0:29
2

Scrum does not operate on projects but on products. "Implementing features" is not a product but an activity that will lead to an improved product. Your idea of a subdivision into the projects you mentioned is far too low level. A more fitting perspective would be to think of whatever product your startup is developing as - well - a product for scrum. Then maybe the whole of your marketing materials could be another "product" with an attached scrum process containing tasks that will expand and improve them.

Scrum operates in areas where complexity is high and predictability is low. If you apply Scrum to a project where it is easy to produce reliable estimates you're only getting partial benefits from it. If you apply it to work where there already exists a close, successful cooperation betwen customer and company you're only getting partial benefits.

Scrum is not without overhead. If you're not getting the full benefits of Scrum you should consider hard whether there isn't a simpler/leaner process you can use that will give you more bang for your buck.

Scrum requires a certain level of interchangeability (cross-functionality). To ensure you can sensibly plan and execute a sprint for most of your tasks it should not matter much who does them.

Finally you're working with only 6 people. That is barely enough for maybe two scrum teams. Running "25+ simultaneous projects" with only 2 teams is going to be nothing but a logistical nightmare.

What should you do?

Assuming you have the necessary basic level cross-funcionality then put all three devs into one scrum team. Group the things you need them to do into as few products as makes sense. For each resulting product assign one of your business people as PO.

For the business side. Closely evaluate if Scrum really makes sense considering you'll have less than 3 full worker quotas available to form a second team.

2

Scrum was originally designed to help development teams co-ordinate and get some work done without being continually interrupted and asked to switch tasks.

In a start-up, it's highly likely that some of your tasks will involve waiting around for things. Some will be experimental and have to be thrown away. Urgent developments may necessitate interruption, quite rightly. Feedback from a wide audience is essential; two-weekly showcases probably won't cut it.

As a result, Scrum (especially as it's typically done, with story point estimation and velocity*) isn't usually a good fit for small start-ups.

There are a few principles which I've taken from Scrum, Kanban and Agile generally which I think are worth following:

  • Visualize upcoming work, work in progress, and work done
  • Visualize the different types of work (by colour or swimlane, perhaps; look at visualizing the source, and maybe also cost of delay - some people just draw a little graph for that; put a date if there's a deadline)
  • Limit the amount of things started but not finished (so if you can help someone else, go do that before picking up something new)
  • Check in regularly with each other (daily stand-ups are good)
  • If you're doing something new, find a way to try it out safely - spikes, prototypes, dry runs, models, etc. - "done" means sharing what you learned
  • Favour delivering small things to small audiences and amplifying what works - see above
  • Retrospect regularly and improve your process
  • Keep your process lightweight and evolve it as required; don't guess at what you need. It might not be Scrum.

If the start-up grows, you'll need to start introducing more formality to the process just to help people co-ordinate. For now, though, lighter is better. You're only six people.

(*And none of that stuff is actually in the Scrum Guide anyway.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.