Learning in project and product teams. Do they learn in the same way?

Learning in project and product teams. Do they learn in the same way?

A team can learn (also) by doing: but what you do and how you do it, influences the team much more than how much and how you do it.

During training periods, sometimes we have discussions about how people are negatively affected by “jumping from one project to another”. In this article, we will therefore reflect on ways and levels of learning during the course of a project or product development.

learning team


Project: what it is and what (doesn’t) happen during its development

Everyone knows – more or less – what a project is: there is a before, a during and an after. At the end of each project, people should have the custom to take some time to reflect on how they worked and find ideas for future improvements (and to respect the twelfth principle of the Agile Manifesto). This is a form of learning, even if it is different from reading a book or attending a training course.

And yet, when you talk to people in a team about when and how often they meet, you find that: they meet at the beginning of the project (with a few absentees), they meet during the project (with varying discipline), but at the end of the project they often “skip a turn“.

Often, it happens that people move on to another project without taking on board what they have learnt during the previous one, because they work on several projects in parallel or they have to start another one straight away.

This represents a missed learning opportunity, when people’s work and time are fragmented between several projects.


Project team and product team

Earlier we said “everyone knows what a project is”. Even if the boundary between projects and products is still blurred and the terms are often used interchangeably.

One possible reason for this could be a mismatch between the outside and the inside of a company. An example: in commercial and communication terms, an organisation claims to make products, but develops them for more or less self-contained projects tailored to the needs of various customers, while the people involved in the team work on multiple projects simultaneously.

Apparently, there is little difference between a product team and a project team:

  • they are groups of people
  • each individual has a set of skills
  • these skills enable an objective to be achieved within a certain period of time
  • each group respects a number of constraints (scope, budget and costs).


Project and product: how to generate value

Instead, there a big difference in terms of how value is generated during product development compared to a project:

  • In product development, value is released over a longer average period of time than in a project, based on results obtained more or less iteratively or incrementally, from time to time.product team
  • On the contrary, in a project the whole process ends with a general and final release, with little or no follow-up on the work done or the results achieved.project team


Project: individual competences and bottlenecks

People skills are optimised to maximise the greatest number of projects. People work “together”, but with discontinuity, poor collaboration and punctual interventions; for then “jumping” to activities of another project.

progetto e competenze

People competences are organised in silos and the attention is on the time management of people. Also, these silos are dishomogeneous: there will be an abundance of some skills and a scarcity of others by choice, by context, by contingency or pure chance. Consequently, people with lower competences or a bigger number of requests automatically become bottlenecks.


Learning in product teams

While focusing on the disadvantages of bottlenecks – unavailability, slowdowns, the need to hire or train people -, we end up underestimating the negative effect on learning.

learning product team

A team dedicated to a product development is exposed to continuous learning: the group has all the time needed to learn and develop proper competences and to explore the context of that product (even if, obviously, this doesn’t always happen in a linear and definitive way). Members of a product team always have opportunities to:

  • Continue to specialise
  • Develop their own “T” model of competences

Finally, since more people expand their competences vertically or horizontally, they reduce problems related to bottlenecks and to exclusivity of certain skills.


Learning in project teams

Also in a project there is a learning path: since the beginning of the process, people have poor knowledge of the project and its context; once the work ends, they have learnt all requested knowledge and competences.

learning project team

However, when a project ends, there is a sudden interruption of the learning process. In this case, we refer to disposal learning: once the project is over, individuals start working on another project and their learning process starts afresh. Of course, this is not done in a drastic way, but it certainly leads to the loss of all the collective learning potential that has taken place during the project.


Further “learnings

The two situations described above – continuous learning in products and disposal learning in projects – represent idealised circumstances: boundaries of the two teams are designed as solid, to represent working groups 100% dedicated to their products and projects.

The reality is different: people are not 100% focused on project or product development. This creates a further deleterious effect on the learning process, the task-switching or context-switching: this situation not only limits people productivity, increasing their cognitive load, but it also limits their learning abilities.


When the context allow to easily “jump” from a project to another (when there is permeability among projects), there are major traps:

  1. Partial and fragmented learning, with no time to explore the domain of all the project and product.
  2. Vertical and specialised learning (utilitaristic vision), when it is much more convenient to remain specialist on certain skills or restricted domains, using personal competences in a plug&play way.

Neither of these two situations is globally optimal; they represent those circumstances of local optimum that most frequently prevent the agile management of work and organisation in the company.


Some advice

Organising and training an entire organisation that works “by projects” towards a “by products” working method takes money, time and effort. For this reason, we share some advice, steps that can be gradually taken, to start improving the way people learn by doing:

  • Making retrospectives regularly (non only the first month of work or at the end, or when “we have time”), with a particular focus on “what have we learnt?”
  • Introducing collaborative practices, such as swarming, mob programming and pairing, so that people with different professions can understand each other’s jobs.
    (For further information on Mob Programming, read the article)
  • Systematically map people’s competences and, above all, dependencies between competences and ongoing projects, to minimise the impact of bottlenecks (and to raise awareness such as “we can’t start this project”).

…and some suggestions

Human Reloaded offers professional training and targeted coaching courses for the acquisition of the Agile methodology, which can be eventually customised according to the user needs and contextual requirements.
Visit the website.

For more technical information on the subject of “projects and products“, we recommend reading the report on the last Agile Reloaded meetup linked in bold.

Read more posts from the same category: Practices and tools for teams

Or explore other categories: Agile projects and products Practices and tools for teams Strategy and organisation