Implementing scrum inside a real-world matrix organized software department

Question

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.

The roles:

• 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.

Answer 1

It sounds like you're asking the right questions and thinking in a reasonable way. As a coach, a couple things jump out as concerns for me:

• The small size of the teams isn't always a good fit for Scrum. You might consider merging the second or third teams into a single team.
• You'll need to work with the owners to ensure that a single backlog exists for the teams to draw from, despite being from difference projects. This prioritization process is very hard at first, but is critical for the teams to have a fair chance of meeting their commitments. This is why Scrum recommends a single product owner... the team needs to trust the single voice.
• Consider using different colored sticky notes or a tag in your electronic tool to indicate which project the work is coming from. This should help with your recognition problems after planning.

Next, just try it... it will work somewhat, but not perfectly, and then you can work with the teams to make it better. This is why the retrospective is so important in Scrum.

If, after giving it a fair trial and pushing hard for a few months, you're still not feeling it work well, you may consider trying out kanban, which seems to work better in environments where there's a lot of requests coming from different directions.