Teams formation in a multidisciplinary company
Hello folks
I’m new here and this is my first post. Sorry if did something wrong.
My name is Greg and I (was) a Head of SW leading three teams. Now as our company undergoes a transformation into SCRUM (pretty much as a whole), I don’t know what I will become. Meanwhile I do have a question.
Our SCRUM coach suggested our executive management to form a so-called product teams. So that we have now three teams that each work on its own project. This creates a lot of problems in a multidisciplinary company like ours. Because there are 4-5 disciplines in RnD like Sw, HW, System Engineering, mechanical engineering, QA… if you create a team small enough that it will be manageable, you end up with 1-2 people from each discipline. This creates bottlenecks, little engagement between team members (SW devs are not interested in optical coatings), and so on
Are we doing it wrong? Should we change something? What is the right way to form teams in a company like ours?
Thank you!
Trying to implement Scrum hasn't created the problems you describe, it"s exposed them. They were covered up before.
Now teams are in a position to deal with them. Each cross-functional team ought to be able to create at least one Done, finished increment of immediately usable quality every Sprint. They"ll identify and self-manage any integration dependencies they may have.
The key to success lies in ensuring a sense of urgency for this change is created, communicated and reinforced from the top, so it becomes more important than the old day job.
Our SCRUM coach suggested our executive management to form a so-called product teams. So that we have now three teams that each work on its own project. This creates a lot of problems in a multidisciplinary company like ours.
A few questions to assist you:
- How many Products were created
- How many Developers (people designing, building and testing the product) do you have?
- Is there a person accountable for being the Product Owner for your Products?
Ian and Chris thank you for your comments.
Ian probably you are right. However before the transformation (we already finishing a second quarter of SCRUM) things did work pretty good. We had team per function.
I get your comment on delivering value in one sprint. The issue is, the pace of each function is very different. Sw is obviously can create value in one sprint. But for example system or mechanical engineers? I can’t see how this is possible. Designing a mechanical change and then ordering the production, waiting for delivery… all this takes weeks over weeks.
Chris, here are some information in the order you asked:
- We have three products which are three different production tools for semiconductors industry
- All in all in the RnD we have 50 employees from different functions.
-
Of course we have a PO in each one of three scrum teams as well as a SM.
Thank you guys!
Greg
(Note: the bold and italics will make sense at the end)
Let me make sure I understand you correctly. You have 3 products and each product has a single Scrum Team of 50 cross functional engineers. The following response assumes that I did understand correctly.
A product can be anything that delivers value to stakeholders, regardless of whether that stakeholder is external or internal. A product does not have to be something that is sold to people although a product can be that. A product could be internal tools needed in order to make those things sold to people. A product could be a component that is used in multiple things that are sold to people. You seem to have had a sales or marketing person define your products. That is fine but it does not have to be how you organize to do the work.
Let me give you an example. A pencil is a product that is sold. However, that pencil is made up of a lead, wooden encasement, eraser, some device that attaches the eraser. Each of those products could be worked on by different Scrum teams. Each one delivers some value to the organization that builds and sells the pencils. Each one could be used on multiple products. Each one has it's own complexities. Then to top it all off, there could be a Scrum team that assembles the pencils from all of those products to create the product that is sold to make the organization profit.
What has happened is that your organization has defined the products that are built and sold to outside entities in order to earn profit. Now, your organization needs to define what products are needed in order to make those products and how to organize product teams to build everything needed.
And I am through using that word. :) I hope this helps.
Daniel, that last paragraph actually makes a lot of sense to me. Thank you for your explanation.
Actually we have 50 people in RnD in total. That’s divided into three product teams of 25, 15 and 10 members in each. The number of disciplines is 5-6 (there is a bit of variation). And this causes all of the problems I described initially.
I get your point on dividing 50 people into sub-product teams, but unfortunately we have 50 in total and not in each product team. I probably wasn’t clear on that one. My apologies.