The Open space on the last day (Friday) of the Scrum Gathering 2007 offered many interesting sessions and discussions. Two of these sessions were: “Product Owner practices – prioritizing backlog items isn’t enough!” and “Integration Teams (from Scrum in the Enterprise) – I just don’t get it!”
The product owner role
Scrum has been used for some years now and is starting to face some challenges. One of these is the Product Owner role. Many projects and companies have introduced Scrum with great success (improved performance for the dev team, progress is visible for the team and the management etc.). But after a period of time the progress is stagnating (after aprox. 3 iterations). The improvements made in the first period are related to issues internal in the team, things they can change them self. After proximally 3 iterations the team starts to face issues that are related to the rest of the organisation and the PO has a central role in this interaction.
The overall conclusion was that Scrum and the current PO role don’t solve these problems. There is a big gab between the PO and the senior management, sales, marketing etc. This area needs more focus and we must find some solutions in order to insure that Scrum continues as a successful framework.
To share our challenges and experiences we decided to create a public malinglist. Information will be published when the list is up and running.
Integration Teams – “I just don’t get it!”
Henrik Kniberg opened the session with the question: “does anyone have a example that shows how the Integration team works?”.
There were many god suggestions:
- The integration team is responsible for infrastructure etc. to make it possible for the underlying teams to test the solution. This is close to Kens defition in “The Enterprise and Scrum”. No one had any expirence with this approach and we didn’t find any explanation on why you need a hierarchy of integration teams to support your dev teams. For me it starts to smell like silos!
- The integration team is a virtual team of team members from the underlying dev teams that is responsible for the integration. No one had tried this and I don’t think that it will work.
- The integration team is only working with the Backlog, breaking down the epics into smaller chunks and defining the user stories. In other words: a team that helps the PO doing his job. This is only suitable in large organisations. The question is wetter this will enforce silos and information handover?
- If the project contains hardware it is not possible to do Continues Integration. Therefore you might need an integration team (the silo way).
Many god ideas but no real life example that shows how this is supposed to work.
It would have been nice if Ken had staid for the open space and joined this discussion!
I need to look deeper into Kens book, because I still doesn’t get it.