I tried to list down 5 models of organizing and leading teams. It could be that some transition stages appear in-between. It is not necessary to go through all of them, so it is beneficial to evaluate the current culture (see the post about it) of our organization and upon setting the vision for our teams, determine where we want to be in a short term. Then, start to work on it continuously and relentlessly. It always pays back.
Let’s look at projects through the correlation between the project “resourcing” and a team building curve:
People working in the project are usually called a project team. They are depicted as “resources” in the start of the project. If the project is relatively big, then a group of e.g. 30 members is hardly a team. We rather split the whole group to the smaller teams – frequently to the design team, development team, testing team…
For people (a team) working together, to achieve a high level of performance, it takes certain time. That time is the project time when people are supposed to create value. As it can be seen from the first figure on the left, the high performance level is achieved towards the end of the project (green area). The orange area bellow the expected level of performance line (red dashed line) generates a certain technical debt (delay), that is eventually (hopefully) compensated in the performing phase late in the project.
When the project is finished a “deresourcing” is done, i.e. people are dispersed over the next projects. They are submitted to pass the similar curve again together with the new project members.
In order to avoid the performance drop, the following setup can be proposed:
The core of operations is the long-living team(s) that works on the prioritized features. Having the phases of the team creation “in the past” as shown on the figure, the team starts working on every new feature from the performing level, ready to create value. There is no waste of time to ‘resource’ a feature. When ready, the team would pull the next feature from the prioritized feature backlog and start with it. In addition, the team is capable of releasing the product after each of the features being created. For a difference to the batch&queue project approach, smaller features and quick releases make our product sooner and more competitive on the market.
Applying this, gradually we started less to use words like ‘late’, ‘delay’, ‘catch up’, ‘change requests’… Each of the teams has its velocity, estimates and with the support of the leadership, process, practices and tools try to add the highest value with as lees effort and time as possible and with the highest quality.
You need a project to develop SW?
OK!
There are a number of aspects for the organization to transform to agile: culture, mindset, management, portfolio, methodology… However, without the real agile teams an organization can… call itself agile.
The aim for a real team is to figure out how to most efficiently reach the goal they have with business people commonly agreed to achieve.
First, let’s mention a multi-skilled ‘property’. We need to differentiate between multi-skilled team members and a team capable to perform multiple tasks. Multi-skilled team members are individuals capable of doing different tasks. This is the enabler for a team to become versatile and as less dependent as possible. However, this is not quite sufficient. For instance, a team has three people that can do development and test and three others that can do configuration management and technical writing. In such a case, an early phase/architect and integration competences are missing. So, the team depends on external competences and help. On the other hand, a team could be cross-functional with all needed competences to deliver a product, but some handover within the team is created due to specialization of the team members. Specialization limits learning of multiple skills. In a case of variations where certain types of tasks come in peaks, there might be challenges to cover them timely without overburdening individuals.
So, both multi-skilled individuals and cross-functionality within the team are necessary for a successful team.
Is that enough?
Let’s mention yet another important aspect – long-lasting. Team members need some time for getting to know each other and to build a team sense, a spirit and consequently a performance. It may take more than a week, an iteration or even a delivery. The members of the team build gradually a personal team awareness or in general: the orientation and recognition of others’ work to efficiently achieve a common purpose. It comes along with trust, openness and commitment. The business dynamics and demand for flexibility may be the main challengers to keep the team together (along with leaders that ignore the importance of this aspect).
Please don”t forget empowerment (see the post) and learning.
Leadertip:
Teams are the core structure of an agile company. We should build teams with a wide picture about other teams, system, company and community. We should not stop treating people as individuals and unique human beings.