Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Early Stage Startup vs Scaling Scrum (after 7 weeks)

Last post 12:23 pm June 15, 2022 by Mario De Caerlé
5 replies
05:45 am June 10, 2022

[tl;dr] ⤵️

We are service company startup with a lot of clients, few developers which are also sales how to manage this to scale up?


First, thanks for the possibility to share my question here. 
A lot of energy and knowledge in one place! 

I tried to find information on forum, but my problem is specific. 



We implemented scrum framework 7 weeks ago, firstly just planning and review, after 3 weeks whole ceremonies + role of product owner. 
Nowadays, it works pretty good. We have transparent on product backlog and our plan for the sprint is actionable, but still we have some problems. 


1. Service company.

We have 3-4 clients and 7 developers, which are developing software in mixed teams. Actually I don't know how to manage a lot of smaller teams, so we have 1 scrum team, 1 PO and our product goal is to get business goal of income, and sub-product goals that's mean goals of clients. We haven't enough space to connect 2/3 developers to 1 client, because we have technological debt = just developer know best about his work. My solution for this is step by step introduce e.g. Nexus to manage "product portfolio" - is it good solution?


2. Multitasking = Sales & Devs.

In 50% our developers are also consultants, we have 1 sales person with we are hardly connected inside sales process. So far, we treated him/her as a client that's mean product owner to get from him tasks to-do. In next week we want to try to get this sales person for the scrum team because our product goal ($$ income) is possibly to achieve only with him. I think about next steps and wondering is making "business scrum team" inside of Nexus framework is a good solution? It's hard to section developer just to support sales as a consultant, but participation inside 2 teams aren't possible :(


3. Sprint review vs Client's portfolio.

Actually, we are giving for our clients 15-30 minutes demo box at sprint review, and give them description/video review inside of task to get information. Is Nexus includes problem of portfolio stakeholders connected to just 1 scrum team?? Anyway, for sure we should prepare contract with clients with the scope of scrum - it's crucial!


To sum up

In long term vision it's going to be easier, we are aiming into enterprise companies, so we will have longer cooperation. 
Actually my main problem is "How to prepare the organization, to scale up scrum framework for this year - up to 50 people on board?"


Thanks for your attention,
Have a wonderful day.
Power of greetings, 

11:09 am June 10, 2022

My advice is to get Scrum working with just one team first, before you even think about scaling.

That doesn't seem to be happening yet, given that you are still reflecting on:

  • how you manage a team, rather than on how it will become self-managing
  • "ceremonies" of some kind which are observed, rather than on the Scrum events which promote inspection and adaptation.

The key is to establish empirical process control with just one team first, identifying and removing the systemic organizational constraints that impede its progress. Failure to do so will result in the scaling of organizational dysfunctions along with various contra-indications to innovation and agile practice.

04:46 am June 11, 2022

Thanks for your answer, Ian!

Sounds like the advice of an experienced scrum master.

I understand that it should be 1 team per X clients all the time, until we catch the basics of the framework.

In fact, we are currently focusing on the ceremony wondering how it should go, rather than supporting the inspection and adaptation ... that's right.

Maybe we don't fully understand the concept of "self-managing", but we try to take care of our duties as sm / po / devs and deliver increments together.


04:38 pm June 13, 2022

I understand that it should be 1 team per X clients all the time, 

Actually is should be one team per Product.  There is no concept of a Client Backlog.  It is a Product Backlog.  One team working on a single product can support many clients as many clients can use a single product.

I suggest that you read the Scrum Guide.  Pay attention to what it says about the focus on products and not clients.  Pay attention that there are Events and Artifacts and not ceremonies.  Pay attention to all of the opportunities for inspection and adaptation.  

There is a lot more to Scrum than using the terms Sprint, Product Owner, Scrum Master, Backlog.  In fact, many companies that use those terms are not utilizing the Scrum framework or using the terms to refer to what is described in the Scrum framework.  They are doing Scrumbut (We do Scrum but we this differently because ...). 

As @Ian suggested, don't even think about scaling Scrum until you have mastered it on a team by team basis. I have not worked in a company that had scaled Scrum.  Those companies had between 6-12 Scrum teams.  But there was no need to scale because each team worked on individual Products and no product had more than 1 team. 

04:57 am June 15, 2022

I very much appreciate being able to talk to you gentlemen! 🙏
Thank you, Daniel, for your comment!

 Those companies had between 6-12 Scrum teams.  But there was no need to scale because each team worked on individual Products and no product had more than 1 team. 

It's so basic, and you've brightened my knowledge so much! 🤯
Scalable scrum models are used towards working on 1 product. 
In our case, we actually focus on several products. 
That's why it hits me so much to say to create a few individual scrum teams working on a few products first.  

With each day and new knowledge, I understand why implementing scrumbut is so easy, but iteratively implementing 1:1 scrum so difficult at the same time, it's beautiful. 


There are challenges in my mind regarding multiplicity of customers, 8 vs 8 developers.
In this case it's hard to have 1 developer per 1 scrum team, plus the PO/SM role is focused on 8 scrum teams.
This is probably not an effective way to solve the problem. 


a) Increase the number of developers, for which there is currently no space (bootstrapping).
b) Reduce the number of customers by focusing all the manpower on achieving product goals faster and more efficiently.
c) Maybe scrum is not the best form of framework at the moment.


12:23 pm June 15, 2022

The main objective in Nexus is to manage dependencies. The easiest way to remove dependencies is to have only 1 team at a time work on a certain product.