Launching 8 teams as 1 scrum master this week, send help!

Oh, and since we have no product owners, we're just going to take engineers and promote them to product owners

Are you sure the organization actually has products? If so, who is currently accountable for product value?

I'd suggest that the first step ought to be to have genuine products, and with owners who are genuinely accountable for them. An informed decision might then be made about whether Scrum is appropriate for a particular product in the first place.

We have about 65 products. We have 3 people who play business analysts, they gather and document the requests from the customers. They then explain that to the engineers, and work gets done. Those people are not technical, so they have no idea how our technical side works, so they're deemed not fit to be product owners according to my director.

So, our new product owners will interact with these 3 people and try to fully articulate the asks and then form a backlog. I am sure at least half of the work would be better suited for waterfall as they're 6 month projects with infrastructure etc... 

To me your business analysts sound like the best choice for the Product Owners.  There is nothing that says the PO has to be technical. In fact, based on the separation of responsibilities it might be better for them not to be technical. What you are being asked to introduce is a proxy PO and that doesn't have much success in my experience.  

If I was asked to create the plan you have been tasked with, the first few weeks of the plan would focus on working almost exclusively with the POs to develop product backlogs so that there is something for the Development Teams to start working with in their first sprint.  That will give you an opportunity to do some one-on-one work with them.  At the same time, I'd set up a couple of sessions where you do some development team training so that they can all learn at least the basics of how Scrum works. 

As for the cadence, you will have to have them all finish on a separate days for 2 weeks.  Since you have 8 teams, I'd reserve one day a week for yourself to regroup. And you should set the expectation with your director that you will not be able to spend much time with any of the teams and that their ability to actually get better at Scrum is going to be below minimum for a very long time. Even if some of them have done Scrum in the past, having new teams form is not going to be very effective. If you can suggest staggering the spin up of teams so that you can split your time across 2 teams at a time, it could improve the team's ability to be successful. 

@Jon Joe, you said "Jokes aside...", so I will try not to make laugh from it :)



I see some.. hmm.. problems here. Lets write down provided data:



- No. of products: 65

- No. of dev teams: 8

- No. of SM: 1

- No. of PO: 0

- No. of BA: 3

- No. of Product Backlogs: 0



I hope, nothing is missing for now.



So where do I would start? I think, that the very first thing to do should be creating a matrix of products and what is their stage of life. I suppose that, going after pareto rule, 20% of them are truly developed, or at least brings the most of revenue, and should be focused first. Going from there keep in mind - one product, one product backlog, one product owner, one scrum master, one development team*.



*if product is really big, then you may consider scaling it up.



According to not so new researches, there is a thing called a context switching, what bothers me is that you mention 65 products and 8 teams, which means 8 products per team on average, due to rule of thumb (proposed by Gerald Weinberg), when people work on 5 different projects at same time, lost of time could be around 80%, leaving only 20% for true work, imagine it with 8 different projects (in our context products), that could easily go beyond 95% of lost time - does this company can afford that kind of cost?



I encourage you to talk with people behind this idea of diving into deep water, and share with them all possible concerns and risks, and try to involve them into this transformation - I would suggest to go at the beginning with one or two teams and as little as possible products for them, and learn and adapt through the way when you spread new approach across this company.

We have about 65 products. We have 3 people who play business analysts, they gather and document the requests from the customers. They then explain that to the engineers, and work gets done. Those people are not technical, so they have no idea how our technical side works, so they're deemed not fit to be product owners according to my director.

So, our new product owners will interact with these 3 people and try to fully articulate the asks and then form a backlog. I am sure at least half of the work would be better suited for waterfall as they're 6 month projects with infrastructure etc... 

Errrrm, I'd bet your company has less than 10 products, likely 2-3 - if not a single one. I'd be extremely surprised if it has around 65 products (unless, of course). To my mind, 65 products are unsustainable unless you are a multinational giant, with thousands and thousands of employees.

Quite possibly, your company develops a product (or suite of products) that it customizes/maintains/services for its customers. As such, I'd argue your first items on the agenda are to formally identify the product, organize it (core - implementations - service, etc), identify the right people for the positions, and last, but not least, discuss how to proceed.

Oh, and we have no backlogs, but we get a week to build them... Oh, and since we have no product owners, we're just going to take engineers and promote them to product owners, but we're going to use a middle man to communicate with the customer, who may or may not respond to emails

How were those products (65, if you will) created? How are they maintained? I find it next to impossible to have a product (let alone 65!) developed in the absence of an emergent backlog.

I think my approach would be to delegate and trust as much as possible, and manage expectations towards management. If you were to attend all daily scrums of the team, this would eat away 2 hours of your 2,5 hour time window.

On the other hand, once you get one ball in the air, you might see seven other dropping going on to crazy results, so you need to manage the expectation that the magic results management might expect from going over to scrum might not happen for a long time. Try to get yourself in the position of a scrum coach with several scrum masters within the teams to be the actual scrum master. Although you'll have to find people willing to take on that role.

Are you sure this wasn't written on April fool's day? This is a joke:

You are asked to create a plan - you're a project manager.

There are 65 projects, with specifications that have been created by BAs and expected timescales of six months. This is being driven by product manager who is still thinking linear.

This is what you do. 

1. get the participants of all your scrum teams together and teach them the fundamentals of three actors, four ceremonies and five values.

2 appoint a scrum master for each team, or a volunteer.

3 ask the nearest to a business owner which eight products they want to be done first and identify the customer

4 send the team to the customer (not email; face to face, teleconference, or conference call). They must participate and engage fully. If they exhibit one of the 20 or more PO antipatterns reject them and abort this product.

5 find out what the vision of the product is and the one thing they want from you.

6 team identifies tasks from the one thing, works out the order and starts the sprint

Yes, it's going to be a crap velocity, but it's far better to get on with the process. It'll quickly settle down.

Once the team start, you go around the eight teams to check how they're getting on and coaching them, challenging them. The customer of each team must come to the sprint demo and each team must do a retrospective.

Have the same cadence for all the teams and don't let it slip. Then the customers all know they are supposed to be in the following sessions at the same time each cycle (possibly two weeks):

- sprint planning 

- sprint demo

- backlog refinement

Don't stagger the team starts. Each team should organise themselves and if they talk to other team members they'll get to learn how to be self-organising. 

Your job? Unblocking bottlenecks. It's not do that yourself, it's find the right person to do it.