INTRODUCTION
In the previous part of the article, we explored the focus and intensity of coaching depending on the iteration phase and the role played by the Scrum Master in this process. I also discussed the apparent difference between a Scrum Master and an Agile Coach, and I made some noise about the tendency to limit the authority of “self-organizing” teams.
In this article, I will describe 10 effective approaches that help teams in a Scaled Agile environment coordinate with each other and share knowledge. Of course, in my usual fashion, the article I had planned to be short has grown quite a bit. However, I believe it has turned into a useful reference material for organizations facing communication challenges in multi-team environments.
Let’s start with the obvious…
Let’s start with the most obvious…training
Spontaneous communication
Scaled Agile frameworks typically extend the standard Scrum framework with additional ceremonies designed for inter-team coordination.
- Nexus thus introduces the Nexus Daily Scrum, where representatives of development teams and the Nexus integration team coordinate with each other.
- Scrum@Scale adds Scrum of Scrums events for Scrum Master and Product Owner cycles.
- SAFe adds a whole lot of coordination within its seemingly Agile hierarchy.
- LeSS adds an additional level of Sprint planning.
These “official” ceremonies are useful, but not sufficient for successful coordination of multiple teams developing the same product. They are complemented by spontaneous interaction between teams. This must be constant both at the individual and at the inter-team level. Organization must provide the conditions and goodwill for spontaneous communication. It may seem to some that such ad-hoc communication noise can hinder the concentration of developers in teams. And partly they would be right. But let’s ask ourselves, what are the consequences of duplicating work, inconsistent development standards, and “soloing” of individual teams in the direction of non-standard architectures, materials, or APIs.
Excessive coordination between development teams is regulated by the product manager and/or Product Owner with proper planning, which:
- Minimizes inter-team dependencies in the development of user stories
- Provides the conditions for the formation of real multifunctional teams that can develop a certain feature from start to finish with their own knowledge.
Spontaneous communication does not arise by itself, but requires positive organizational conditions.
Open Space (Technology) - OST
A method developed between 1983 and 1985 by an organizational consultant Harrison Owen. He asked himself why coffee breaks are usually more productive than the meetings themselves. Over time, he developed a method for organizing meetings where a larger group of people self-organizes around an important, shared topic. Instead of a predetermined agenda, participants define the discussion topics themselves, split into smaller groups, and talk about them.
Main principles of OST:
Whoever comes is the right one.
Whatever happens, had to happen.
When it starts, it’s the right time.
- When it’s over, it’s over.
Added is the two-foot rule: if a participant sees that they can learn or contribute more elsewhere, they should simply get up and leave.
OST is especially useful for addressing complex challenges where there are no clear solutions and the collective knowledge of the group needs to be harnessed.
Opomba: Izraz “Technology” v nazivu te tehnike je malce zavajajoč. Izraz naj bi pomenil “strukturirani pristop” in nima zveze s tehnologijo ali imenom kakšnega podjetja. Je samo nerodno poimenovana tehnika. Tako ali tako pa vsi uporabljamo le izraz Open Space.
What an OST meeting looks like
Context
The company wants to implement Agile in several departments, but there are many open questions such as:
How will business units cooperate with development?
How to adjust reporting and planning?
How to avoid duplication of work?
Meeting
The moderator opens the meeting with an overarching theme, for example:
“How will we as an organization successfully transition to an Agile way of working?”
Participants (e.g. 50 people from different departments) themselves suggest sub-themes that they consider important. A couple of examples:
What does Agile mean in finance?
How will we report progress to management?
How will progress be evaluated?
- How will developers cooperate with after-sales support?
- How will we measure improvements in logistics processes?
- An agenda is thus employee-shaped agenda is created on the whiteboard.
- Each topic gets its own space and time. Participants divide into groups according to interest.
- The discussion continues in groups, which record their ideas and suggestions.
- The two-foot rule applies – everyone can move to another group if they think they can contribute or learn more elsewhere.
Result
At the end of the event, contributions of the groups become a “collection” of ideas, questions and solutions.
This way management and teams get an unfiltered insight into what is really important to employees.
The event strengthens team spirit and engagement in the process, as participants see that their wishes, interests, and fears are taken into account.
The result of an OST meeting is not necessarily solutions on the spot, but rather an awareness of what is important to employees, what their fears and reservations are. In the event that the OST was convened for the purpose of finding solutions to complex problems, the result is a broader insight into the problem and a list of possible solutions, which must then go through product discovery verification.
In practice, OST is used for strategic discussions, team building, finding innovations and solving complex problems where there is no easy answer from above and consensus and mobilization of the intellectual potential of the group is needed.
World Cafe
Like Open Space, World Cafe is intended for the exchange and enrichment of knowledge in larger groups. The basic idea is that participants sit in smaller groups (like in a cafe), where they discuss a certain topic in a relaxed atmosphere. This topic can be finding a solution to a certain problem or generating new ideas. After a certain time, the participants move to other tables and continue the discussion in newly formed groups. In this way, they take with them key thoughts from the previous group, which are then upgraded in the new group.
After at least three rounds of such “migration”, participants can return to “their” table/group and make a synthesis of the acquired knowledge and ideas.
The groups then present their insights at a joint debate. In addition to new ideas, this makes it easier to identify useful patterns, which are then included in various aspects of the business.
We practice two forms of World Cafe:
Variant 1 (most common): all tables/groups discuss the same question. As people move between tables, ideas circulate and are enriched.
Variant 2: different tables debate different but related questions. Rotations allow participants to touch on several topics that are part of the same broader problem. This variant is quite similar to Open Space.
What a World Cafe meeting looks like
Common question for all groups (variant 1): “What could we do to improve cooperation between departments in our company?”
- 1st round (20 min): groups start the discussion and write down their ideas.
- 2nd round (20 min): people move (scattered!) to other tables. In the new group, everyone presents ideas from the previous round, which the new group then upgrades or creates completely new ideas based on them.
- 3rd round (20 min): another exchange, new groups expand or challenge already written proposals.
- 4th round (20 min): if needed…
- Conclusion (30 min): joint debate. Groups present their ideas, findings and insights. This is followed by a joint search for patterns and decision-making.
An additional bonus of this technique is the relative consensus regarding final decisions, because these are based on a common understanding of all groups and all participating individuals, the level of opposition is lower.
The essence of the World Cafe approach is the incremental enrichment of ideas.
Lean Coffee
It is intended for focused discussion and a quick overview of current problems without a pre-determined agenda. Due to its structure, it is usually performed for smaller groups than World Cafe or Open Space.
Outline of Lean Coffee:
Whoever wants to participates. Participants gather in front of the Kanban board where they create an agenda on the spot. Participants suggest topics, then vote on which ones to address.
Topics are written in a Kanban board with columns:
For discussion
Discussing
Discussed
The voted topics are marked and individually moved to the “Discussing” column. The discussion is time-limited (timebox approx. 8 min.). After the timebox expires, participants vote whether to continue with the same topic for another timebox, or continue with the next topic.
The characteristic of Lean Coffee is the focus on self-organization and the priorities of the group. It often happens spontaneously.
Scout
A simple technique for cooperation and information sharing between teams is for the team to send a scout (not a Scrum Master!!!) on a scouting mission to another team to find out something useful there and then report back. This is an easy way of communication, which is useful when something minimal needs to be communicated or to find out who in another team it makes sense to talk to about a certain topic.
The most suitable time and place for the scout to “go into the field” is the Daily Scrum of other teams, where they act as a silent observer.
Which teams? Most often those with whom the originating team had a joint Sprint Planning or backlog refinement.
An additional bonus of the scout is that he sees how the Daily Scrums (and dynamics) of other teams are going. If resistance to this ceremony begins to appear in the team, the Scrum Master can suggest scouting the Daily Scrums of other teams. In this way, members strengthen their awareness of the importance of this ceremony and/or gain new ideas for its implementation.
Scout is fast and fun low-level tool for exchanging smaller volume of information between teams.
Traveler
When we have experts with specific knowledge in the organization, which all development teams occasionally need, they can become travelers. The situation where certain knowledge exists only in an isolated “silo” is of course not desirable, but a traveler can be a transitional solution that alleviates such a situation.
The traveler works as a regular member of the team for one Sprint. He also shares responsibility for the result of the work with the regular members of the team. It is important, however, that the traveler also has a secondary goal – to reduce dependence on him/herself, usually by teaching others. It should be noted that teams that do not have a traveler in this Sprint, are left to their own devices and must figure out how to achieve their goals without the support of the aforementioned expert. This is also an aspect of team self-organization.
A traveler therefore avoids helping other teams during the Sprint. This is important because it encourages the dynamics of the current team to focus on learning from the traveler, who is visiting only for this Sprint. In this way, the dependency on rare expert knowledge possessed only by certain individuals is eliminated.
The consequences of the traveler being unavailable to other teams during one Sprint are not as severe as they may seem at first glance. The Product Manager/Product Owner, after all, in a multi-team environment plans the Product Backlog with the aim of reducing inter-team dependencies anyway.
Traveler is a transitional measure with which the organization in a multi-team environment, alleviates the negative consequences of knowledge “silos”.
Traveler community
Due to the wide experience they have gained from working in different teams, travelers can form their own group. At these meetings, they exchange information, knowledge, ideas and gossip. In the final phase, they can even decide to organize an Open Space to which all interested parties are invited.
Why shouldn’t travelers share knowledge and experience with each other as well?
Communities of interest / practice
In Agile, Communities of Interest (CoI) are voluntary communities of people who are united by a common interest or topic, but not necessarily working together on the same product.
These are informal and self-initiated groups where members from different teams (sometimes even from outside the company) share knowledge, experiences and good practices about areas that interest them. For example:
Community about UX/UI design,
Community about test automation,
Community about DevOps tools,
Community about Scrum Master practices.
There are also Communities of Practice (CoP), which are more formal and permanent, tied to a specific profile (e.g. Scrum Master CoP, UX CoP, CAD CoP, Animation CoP).
CoI and CoP are self-organized groups of employees who are united by a common interest. Meetings are ideally held during working hours, but often also outside (beer helps).
Component community with component mentor
Practice originates from Large-Scale Scrum (LeSS) environments. The purpose of a component community is similar to that of travelers. It seeks to eliminate “knowledge silos,” which are usually a bottleneck in the process, and to enable knowledge transfer between teams.
Component community
It is a community of people who deal with the same technical component (e.g. database, UI framework, API gateway, MFA…). Members come from different feature teams, but they are united by the fact that they often touch the same component in their work.
Purpose of the community:
- harmonizing guidelines, architecture and good practices,
- sharing knowledge about the component in question,
- solving common problems,
- avoiding duplication of solutions by teams.
Component mentor
Is a person with the most experience on a certain component (but does not have ownership over it).
His/her role is more mentoring than operational:
advises teams that encounter the component,
teaches others and thus reduces dependence on himself,
promotes good practices so that the component does not become a bottleneck in the process.
The component community can decide to organize a Multi-Team Design Workshop (below) if necessary, where it will present its component to the wider organization.
The purpose of the component community is to purposefully reduce and gradually eliminate the knowledge silo about a certain product component.
Multi-Team Design Workshop
An Agile practice where several teams gather to jointly design a solution for upcoming work.
Instead of one architectural team or a few seniors preparing the design, all teams participate in determining how to realize a complex functionality.
The purpose is to ensure:
- alignment of architectural and technical decisions,
- common understanding of the requirement,
division of work between teams in a meaningful way,
- while at the same time giving teams enough freedom for innovative execution.
Multi-Team Design Workshop meeting
The implementation of the Design Workshop looks like this:
- Preparation: Product Owner and stakeholders present the planned functionality or larger backlog item.
- Finding solutions: Teams mix into smaller groups and propose possible designs/solutions.
- Groups present their ideas.
- Consolidation: Teams select or combine the best approaches, identify dependencies and minimize them as much as possible.
- Division of work: With a unified understanding of the whole, teams take over individual functionalities in the realization.
The purpose of the Multi-Team Design Workshop is to coordinate several development teams in the realization of large functionalities, so that there are no inter-team dependencies and duplication of work. The event can be carried out as part of a multi-team Sprint Planning.
CONCLUSION
With this, we have concluded the mini-series of articles that took us from team formation, through adapting the approach to the team’s maturity, and finally to coaching and communication approaches within the development cycle itself. I wish you successful work and many development teams.
