Teams formation in a multidisciplinary company

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.

It seems that forming small teams with representatives from each discipline is causing issues like bottlenecks and limited collaboration. In a multidisciplinary environment, one potential solution is to create cross-functional teams that include members from each area but are organized around specific outcomes or product features, rather than a single project. This can help enhance focus, improve collaboration, and reduce inefficiencies. Consider revisiting team composition based on functional needs and communication, ensuring that teams are aligned with SCRUM principles but remain flexible.

Karl, it looks like your comment is somewhat similar to Daniel’s last paragraph.

The issue with this approach is that you’d need same number of disciplines involved in even smaller team and this will worsen the collaboration and bottlenecks. 

What I think of is to form teams around disciplines and not products. This way features will be organized and delivered by homogeneous teams. For example, sw team delivers all of the sw features for all three products. This will result in better collaboration within the team and there will be no bottlenecks, no dependencies on a single contributor. 

What do you guys think of it?

This is not going to make things move faster. In fact, it could exacerbate the problems. What you are doing is creating possible "choke points".  If one discipline is able to do more work than the others, for whatever reason, then the handoffs between the groups can cause things to bottleneck. You are already seeing that as you mentioned in your original post. 

The concept of a cross disciplined team is to have all of the skills needed to do all the work on a single team that is operating on the same cadence/schedule. You want team members that feel like they own the products they are creating and will do anything necessary to ensure that the work is done. You want to have something that is potentially releasable to the stakeholders at the end of every iteration. Even if it is not the complete solution, there should be enough that can be given to the stakeholders to gain feedback that is used for course correction and adaptions. 

Moving a company to an agile mindset requires a lot of changes.  For example, your software devs need to care about optical coding if that is part of the product that they are building. Because if there are problems there, their work will never be used and that can cause a lot of frustrations. If you try to implement practices that are not beneficial, then stop trying.  You never said why the company decided to move to the Scrum framework.  What motivated them to do it?  Did an executive read an article and say "we have to do this" without really understanding what "this" is?  Scrum does not work for everyone and often what Agile Coaches suggest isn't true to the Scrum framework.  A company can be agile without having to adopt specific practices.  The word agile is an adjective meaning being able to move quickly and easily.  Animals are agile. Athletes are agile.  Both of them view their surroundings, evaluate the situation and adapt quickly to improve their positions.  That is what organizations in today's economies need to be able to do. 

Daniel,

Thank you a lot for your feedback. I will address each point in your post. 

First and foremost I don’t want to fight the change. We are already in a product teams and we try to sort out our issues. Let’s see where this journey takes us.

I just don’t like to follow a pattern if I don’t see a value and always question the way we chose. This is how I am. Probably not all SCRUM principles are a good fit everywhere.

In my original post the bottlenecks I described do not come from the different pace of each discipline but rather from having too few members of that discipline within product teams. If for some reason a single SW Engineer takes a sabbatical - this halts all he SW and product development. As such, in this regard, having a SW team won’t cause any bottlenecks. If they will finish the defined SOW that they have to deliver to for example, SYSTEM TEAM, they can focus on improving infrastructure or paying the accumulated technical debt. Balancing workload in a team is way easier than balancing workload of a single engineer. Hope this point is clear.

Regarding a single sprint artifacts or deliverables. In some disciplines creating a real value to demonstrate to a stakeholders takes months. Imagine that we are developing a space telescope (which is not far from what we do). What value (not only designed mechanical part) can a mechanical engineer create in one sprint? For example he works on a robotic arm for self-servicing of the satellite). Even a small change requires multi-sprint feedback loop.

I just can’t see how so different disciplines work together in one team with single pace of sprints. 

SCRUM is not a single agile process. We could have chosen any other from tens of other processes but as you correctly hinted it, our executive leadership have chosen that because it is there without proper understanding of what it is. Pretty common situation nowadays.

Your last words are a pure gold. In our case the management won’t listen though. How pity.

Thank you again. I value and appreciate your help a lot!