Community of practice in agile teams

A consistent implementation of agile working includes that Scrum teams work co-located - i.e. in a shared space. In the development of mechatronic products, this means that specialists are removed from their specialist groups to sit with their project team members. Decisive success factor: the common project focus. Disadvantage: The exchange within a specialist discipline becomes much more difficult. Possible solution: the formation of guilds. This way, in addition to the project focus, the subject focus is not lost.

Scrum teams sitting together

Scrum teams have all the resources they need to develop the desired product. Each team is interdisciplinary and its members are drawn from all the disciplines necessary for successful product development.

In addition, it is important that a Scrum team is co-located. This means that all members sit together in the same room or on the same floor space. The advantages are obvious, or rather close, because: Close cooperation is thus facilitated and communication improved. This has a particularly positive effect on arrangements between official meetings or events. Experienced developers know that the need for this is sometimes great.

The moment the first Scrum teams are launched in a company, the consequence is that technical specialists such as design engineers are pulled out of their existing group - usually a design team - to sit with their project colleagues. This measure significantly increases the focus on project success. The Scrum team members identify significantly more with their project.

The professional focus suffers

However, it did make sense that the designers (or, of course, other specialist disciplines) sat in a group. This promoted exchange within the discipline, set standards and, above all, enabled experienced specialists to take new experts by the hand.

The possibilities for this are clearly limited by co-location in the project team. From the company's point of view, however, these aspects are important and should by no means be neglected. It even goes so far that this lack of exchange within the department is often cited as a reason for not letting the project teams sit together permanently. However, this is a deceptive fallacy, because there is a simple, proven method to reconcile both. On the one hand, there is the enormous advantage of a Scrum team that sits closely together, and on the other hand, there is the possibility of a demand-oriented exchange within a discipline based on agile principles.

Guilds as a bridge between project and subject focus

A guild - also called a CoP (Community of Practice) - is a cross-team association of people interested in a topic. As a rule, these are specialised disciplines, such as the above-mentioned designers. But other interest groups can also join together. Examples of this are digitisation groups or architects for a product family, who could come from several disciplines. Ultimately, the need decides where guilds are formed.

Rules of the game for success

For such guilds, there are rules of the game that should promote that, on the one hand, the guild's way of working fits the agile teams and, on the other hand, that the desired results are achieved.

Guilds ...

  1. ... are hierarchy-free like a Scrum team. That means there are no "reporting lines".
  2. ... have a leader - a guild master, or guild leader. Ideally, a recognised specialist could be elected to this role, or a leader could be appointed by management. If a Scrum team member takes on this role, the capacity for this task must be taken into account in the sprint planning. The guild master assumes specialist responsibility for a specific topic and thus has specialist decision-making authority on topics that cannot be brought to a consensual solution within the guild.
  3. organise themselves. Every member of the guild can equally contribute to topics and participate in decisions. This means that every team member has an influence on the agenda and ensures that the guild does not become a "palaver committee".
  4. ... (also) have a standardisation function - as far as necessary and reasonable. The definition of, for example, design standards or the use of CAD tools cannot, of course, be left to each Scrum team. From the company's point of view, it makes sense to define these topics across the board. This can be to the disadvantage of individual teams, but it can still make sense after weighing up all the arguments.
  5. ... meet regularly and the capacity for this is taken into account in the sprint planning. Participation in the guild meetings is mandatory for the participants.
  6. ... organise (together with the managers) the team-wide technical coaching of young or new professionals in the Scrum teams. This is especially necessary if there is no other (suitable) specialist from this discipline in the respective team who could take over the coaching task.

Guilds as an enrichment alongside agile teams

In our projects around agilisation, we - the consultants of CO Improve - have already introduced many guilds and coached and supported them in their first active phase. In all cases without exception, these guilds have been found to be a useful asset. They fill the hole that dedicated professionals perceive when they put their focus entirely on project success. But it is definitely a challenge to implement a guild in such a way that it ideally supports agile working and is not perceived as a hierarchical relic from the "old organisation". This is exactly where professional support is very helpful and extremely promising. Feel free to contact us.

Your benefit

  • You do not lose the technical focus through the formation of Scrum teams.
  • The cross-team professional development of relevant topics is ensured.
  • Even inexperienced specialists in Scrum teams receive support in their specialist discipline.
1.0