I'm working as a manager of the software department in our small sized company (~50 people). I have three development teams, 3-4 members in each. One of the members in each team is in the role of the team leader. One of the teams is mainly working an a single project and it happens rarely what they have to help out somewhere else. The other two teams work on 2-3 projects (same for both teams).
My predecessor used no scrum or such, basically he just assigned work very loosely in a daily to weekly rhythm. Of course that lead to the absence of any project planning/controlling artifacts or processes. Nobody ever knew that could happen in the next time and nobody could predict when any task will be completed. You can imagine how the projects run.
I'll have the task to move on from here and I decided to start implementing scrum into the teams. Of course I'm still very unsure about some things and I'm in need for some advice from people which traveled a similarly road much farther yet.
We have custom driven project with classic project managers and project engineers. Since they act already like product owners, I think best would be to keep that. Would you agree?
We have also some intern R&D like projects to improve our products or dev tools on our own. All kind of people can propose or push-start such projects. I usually manage them from start to end. I would be in the role of the product owner for them. Do you do the same?
Management of the collaboration and control of the different Teams. That is one of the main things the company does pay me for. I think of implementing a thing like scrum of scrums between me and the team leaders. I would be in the role of the scrum master here, which may or may not bite with the product owner role described above. Would you recommend it to me?
The procedures and artifacts:
I want to start slowly, making sure everyone is following on our path.
The things I want to begin with is maintenance of release- and sprint-backlogs capturing user stories, sprint planning with cutting the stories into tasks and maintaining task boards, and daily stand ups.
If that works I would go on introducing estimations, burn down charts, measurement of development velocity.
Afterwards maybe measuring developers individual estimation optimistic-factors to improve project finishing forecasts.
Would you agree to that sequence or do something else?
The thing causing me the most head aches for now is how to do all that while working on different projects at the same time inside a matrix organization.
The backlog: Should I have a single one capturing all stories for all projects? That would probably lead to complicated sprint planning.
Or better a single backlog for each project? But how would I capture priorities between different projects then? For example story a of project 1 is most important, then comes story 1+2+3 of project 2 and then story 2 of project 1 and so on.
As hard as the above is the imagination of the sprint plannings for me. Teams should pull stories from the backlog. But how should they do that if several backlogs would exist and the priorities are going zig-zag between them?
The last two points confuses me most, but I would have to solve them before being able to do even the first step.