A London-Turin retrospective

sherlock Prologue (suggested theme music for this post here)

At the end of June I moved to begin a secondment for one year in our London office. One of the purpose of the secondment is to help to implement a software developed by my team in Turin.

So I temporarily dropped my Scrum Master role and I became Tech Leader of a new project in UK that had to use the new software: we went live at the end of July, but a lot of things happened even if the launch has been a success.

During that time I had (I’m still having) biweekly meetings with the Product Owner of my ex team to monitor the status of the project, the problems using the new software, the difficulties getting support and so on, but with the new Scrum Master we decided to run a retrospective at the end of the delivery to gather some information and to improve the software, the way the projects should use it and the support provided by the Turin office.

Yin-Yang-small Projects and Products Yin-Yang-small

Generally speaking it is very complicated the relationship between product teams and project teams because of a lot of reasons:

  • different roadmaps
  • different needs
  • different stakeholder

The two teams are bound, but at the same time they need to be independent.

Needless to say the support is a classic field where to find solutions or grounds for conflict.

If in a similar scenario you put a sea in the middle and two different languages you can figure out how it’s easy to over complicate a complicate situation.

We ran this retrospective the last week and I and the Scrum Master in Turin had to manage it via Skype because the participants were, obviously, from UK and IT.


From our side participated: the Project Manager, a senior developer, a tech leader of another project to get some information about what happened to our project and I as a tech lead of the project and as facilitator of the retrospective on this side.

From the Italian side participated: the Product Owner of the software, the team that is in charge for the software and his Scrum Master.

We ran a “Glad – Sad – Mad” to gather information.
In this case it was absolutely perfect because most of the problems were not related to a tech field, but about the “communication” in any form you can decline this concept.

Let me be generic using an example of a typical relationship/dependency between products and projects:

A Project Team’s point of view

A Project team has the perception that the Product team doesn’t understand the complexity and the needs of the Customer represented by him.
For the Customer’s perspective the only existing roadmap is its own and it should lead to the delivery smoothly and quietly. A product or any other software in his vision are only technicalities: if a product/software doesn’t solve a specific need, generically, they can decide to look for another that suits better.
From the perspective of a Project Manager to be not able to reuse an internal product because its status is not enough for the needs of its Customer is a problem and a loss for the Company.

A Product Team’s point of view

A Product team has the perception that the Project team doesn’t understand the needs to improve the product following a Vision that should cover many needs and not a specific one, looking to the future and not only to the present.
Putting into the Product too much business logic can make happy that specific Customer, but at the same time the risk is to have something too much specific and so useless for any other possible Customer.
You risk that the cost and the maintenance of the product increase without any control and to have a lot of “branches” of your software because any specific need leads the software in a direction that can be irreconcilable with other needs.
At that point to release bug fixing, general updates or features, becomes very expensive.
This path commonly leads to the creation of a lot of teams to maintain every single different version: at the end the product loses its identity and vision.

And then?

Looking to the needs of Product and Project the main problem is that…both are right.
A technical solution to solve the technical part of the problem is to follow the Open/Close principle.

Keeping the software open for extension is a good way to proceed, but a different problem comes: who is in charge for the extension? When a feature should be an extension and when it should be in the core?
Simplifying: who pays?

In a day by day situation it can be translated in “I need this stuff, but I don’t have time/resources, some help please?”


And now we are back to our retrospective: I was very very curious about the results from both side.


The Project team

The launch went well so there were no complaints related to a specific episode, the project team highlighted that the software was been easy to manage from the begin and the productivity wasn’t decrease in a perceptible way (10 points to Ravenclaw!).

The problems were more related to the configuration and initial setup and to the usage of specific components not well known by the team.In case of problem/debug/misconfiguration the project team felt more comfortable asking to the product team.

The Product team

The product team were happy about the result of the launch and about the adaptability of the project team that started to develop with the new software with the appropriate attitude, developing by themselves the few extensions they needed (10 points to Hufflepuff!).

The problems were more related to the support, sometime very very time consuming. The product team highlighted that in some cases the support could be avoided just putting a bit of effort and following the documentation.

Both teams agreed about the complexity of the configuration.


What about the actions?

The product team will work on the documentation and the configuration in order to give in the future something more simple.
The project team will work on the creation of checklist and internal documentation to manage troubleshooting without to go to the product team every time.

Both teams agreed about the need to create standards and best practices for the creation of extensions in order to provide the proper quality.
A common repository where to put them will be part of a common work that will involve more teams.

Personally I’m amazed by the result and by the reaction of the teams: no blame culture, a lot of suggestions on how to improve.

I will check how much, in the future, the different roadmaps will make easy and possible to put in place the actions 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s