R&D organization

If there is really one product, how do those 500 people currently integrate their work?

Are business opportunities being missed due to an inability to create and release a single product in a timely manner?

What would be the problem that you are trying to solve? What's the added benefit?

Release date is defined common to all subproducts. Customer can install whole product or can select some components. Support issues are routed to each subproduct.

Regarding second question I don't know the answer, because I do not have much contact with sales people. I am most of my professional life working with product development. From product perspective it seems better to have one product owner. In order to change it require mental change for the workers and also product directors.

The problem is that my sub-product is going to be merged with the the others in next version. My team (50 persons) is going to be reorganized. I work with extension. For years we suffer lack of help from other sub-products. However it is common responsibility of whole product to solve requests from local market which we are solving. I am planning to publish open letter to my colleagues in other products. But before I do this I first will send my ideas to my colleagues and to my boss and to boss of my boss.

I am writing to this forum to find out whether it is possible to organize 500 people software factory according to scrum.

My team (50 persons) is going to be reorganized

My advice would be to focus on one team of 3-9 people first, regardless of product. That team should be able to deliver usable features of release quality each and every Sprint, and without external dependency.

Is that possible now...or would significant organizational change be required for even just one team to implement Scrum well?

Remember that the first choice is to descale a challenge so it can be dealt with using single-team Scrum. Only after Scrum has been mastered at single-team level should an attempt be made to scale agile practice further.

Thank you, I will give a thought to this advice.

I agree with @Ian's last comment.  If you can't get one small team successful, it will be near impossible to do it with 56 (500/9). 

I don't think that you have 1 big product. I believe you have a product suite. Each product should have their own Product Owner.  The cross product cooperation should occur at the Product Owner level.  They should all be working together to provide Product Backlogs that allow the best value to be delivered across the company. That being said, get one and only one product to commit to the experiment of using Scrum. Take 1 small team from the Product to focus on delivering increments of value.  Let them learn how to do it and be the example to the rest of the organization on how it works and the benefit of doing it. 

I would not even start thinking of scaling to the large scale you mentioned.  And if you do attempt that in the future, bring in an external coach (team of coaches) because they will not be influenced by old rules and can help steer you to a new way of doing things. 

Yes, external coach is probably good idea. I probably should live in a small team, as you suggest. What is hard to agree for me is that we are changing the same components as the other products or sub-products. We work in extension and we often destroy or change the logic which was created in so called "core" components. How could we cooperate ? You are saying that it should be on product owner level. OK, then I am writing email to product owner...

Let me pause. Is it OK for me - as a team member to contact my product owner ? Yes, it should be OK.

Is it OK for me to contact the other product owner or architect ? My project manager is telling me that it is not OK. I should wait for my manager and their manager to agree on cooperation. Ok, let them agree. How can I help my manager to achieve better cooperation ? Is my strong believe that we should be working together a help for my manager ? Maybe I should bring customer perspective. Customer don't care whether given piece was developed in "core" or in "extension". It should be working good. Is this perspective be helpful for my manager ?

Look at the section of the Scrum Guide that talks about the Scrum Master's services to various roles. (https://www.scrumguides.org/scrum-guide.html#team-sm).  Notice the service to the Product Owner and the organization. 

To the PO

• Finding techniques for effective Product Backlog management;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility;

To the Organization

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team;

Since the POs on the other teams are part of the organization, why would working with multiple Product Owners to help them understand product planning in an empirical environment be wrong? Aren't all the managers and architects part of the Organization?

Your question about whether the perspective is helpful for your manager can only be answered by your manager. But as a Scrum Master you are providing a service to them in trying to help them understand better how their interactions are hindering/helping the ability of your teams to execute.

Daniel, from Scrum Guide point of view you are right. Anyway fact is that I received reprimend from project manager. The reason is that my manager and their manager should agree on the other person time spent on our project.

My conclusion is that managers are managing time of employees even in scrum. They cannot manage WHAT I am doing, because I just take item from backlog. They can manage FOR HOW LONG I am doing something, because they assign people like product architects to different projects. Another thing is that product architects are not part of the development teams. They are serving all the teams working on given area.

@Marek, I know this doesn't help you much but in my opinion there is nothing Scrum about anything being done at your company.  If you still want to help them the best you can do is coach on general agile practices that use empiricism as the basis.  You can still be an agile company if you can get them to do so. I would suggest talking to them and being very forthcoming with the fact that they are not doing Scrum and really shouldn't be trying to say that they are. Let them know that you will help them find a balance between their command-control desire and a servant-leadership method that is so much more successful in today's environments. (Of course you should probably use different words than the ones I just used.)

Maybe by getting them to start adapting slowly they will eventually come to realize that doing true Scrum would be better for them.  But it will require a very large shift in management philosophy.  Companies have to start the Agile Transformations at the upper levels in order for it to be successful.  Otherwise you are implementing an Agile Revolution and history shows us how successful most revolutions have been. 

Yes, it is slow process to change organization. The other product group is much focused on finalizing some deadline defined by management - new user interface. Therefore they make sure all employees spend time on this goal not being disturbed by external questions. This is traditional management, not scrum, I agree.

I exchanged emails with that project manager and she understands my point of view. I sent her also thoughts from Covey's book "The 8th habit" where author explaining the difference between command-and-control management in industrial era and self-organized man in new information or knowledge era. She responded that even thoughts in book are interesting but each man is different and it is not easy to convince everyone and change way of working.

Regards,