In the previous two articles, we learned about Tuckman’s team development model and later, how a leader adapts their team guidance approach based on the achieved development stage.
In this post, we will briefly look at how the Scrum Master educational focus is directed within each iteration. In the second part of this article, we will look at how teams in a Scaled Agile environment share knowledge and experience with each other. Training
According to the Scrum Guide 2020, a Scrum Master (I quote):
“Is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices within the Scrum framework. “
From a knowledge transfer perspective, this doesn’t just mean that the Scrum Master trains team members about good Agile practices and tools used by the team. It also means encouraging members to exchange important information and acquired knowledge both within and between teams.
TEACHING
Teaching, in any of the forms listed below, is an important tool for achieving effectiveness.
Training
Classical, structured teaching following a prepared curriculum. The Scrum Master typically uses this teaching method:
- At the beginning of Agile transformation, when stakeholders need to be mass-educated about the chosen Agile framework.
- When welcoming new team members. Regardless of whether they’ve previously worked in the same Agile framework. Implementations can vary significantly between organizations, and even within a single organization.
- When introducing participants to ways of facilitating Agile ceremonies. Especially Sprint Retrospective, which is quite a structured event. The goal is for the team to eventually take over ceremony facilitation themselves (self-managed team).
In a Scaled Agile environment, teams also practice frontal education among themselves. An example would be an inter-team workshop presenting a new API version that all teams will need to start using in the next iteration, or a presentation of a new regression testing platform. Such workshops are called and conducted by developers themselves. More on this in part two of the article.
Coaching
This is instructing on a specific topic that later expands to related topics and deepens based on interest and needs. An example of coaching would be teaching a Product Owner about prioritization schemes and advising on choosing the most appropriate one.
Coaching is less structured than training and adapts to ongoing needs. It can be individual or group-based. The last part of the article is dedicated to this form of teaching/instructing.
Mentoring
Mentoring is more of a professional relationship than a purposefully directed activity. Topics are chosen by the mentee, while the experienced mantor provides advice and help as needed. A small part of mentoring is also osmotic communication.
Note: In American universities for example, mentoring is taken very seriously. Mentors are evaluated by students and consequently rewarded – or dismissed. This attitude also spills into the business world and is practiced by many US development companies. Europe – we have much to learn.
So training is frontal, usually at the start of an activity. Mentoring is ongoing, as needed. And coaching…
COACHING IN DETAIL
The goal of coaching from a Scrum Master’s perspective is continuous process improvement and helping the team overcome obstacles.
Scrum Master conducts coaching at two levels: team and individual.
Team coaching is more pronounced at the beginning and end of the Sprint, as that’s when group ceremonies like Sprint Planning, Sprint Review, and Sprint Retrospective take place. During these times, the team needs guidance regarding the purpose and effective execution of these events.
During the iteration itself, there’s time for individual coaching. Team members will typically ask for help in removing specific obstacles or approach the Scrum Master with complaints or suggestions. Individual coaching maintains confidentiality between Scrum Master and team member. Scrum Master must check over time whether the raised issue has been resolved.
I’ll interpret Lyssa Adkins, a well-known Scrum trainer, who described four important characteristics of Scrum Master coaching:
- Don’t offer solutions to the team or individual. Even if you know one. Through suggestions and guidance, you should meet halfway. Even a less optimal solution proposed by the team will be implemented more effectively than an “ideal” solution suggested by, for example, Scrum Master. If team sees the solution as their own, they’ll be more committed to its realization than if it were delegated from outside.
- Maintain confidentiality. This applies to both individual and group coaching.
- Collaborate with managers regarding changed metrics for evaluating and rewarding team members if they’re still embedded in the organization’s hierarchical structure. The goals of functional managers (who aren’t part of the Agile team) need to be aligned with the goals for which the teams were formed – much easier said than done.
- Maintain a positive attitude towards all stakeholders. Regardless of personal opinion. There’s something precious and unique in every person.
SCRUM MASTER vs. AGILE COACH
Many organizations engage Agile Coaches in addition to Scrum Masters. What’s the difference, and does it really exist?
The perception of these two roles in organizations is usually similar to this:
SCRUM MASTER:
- Is PART of one or more Scrum teams. This allows them good insight into the dynamics and development of individual teams and their guidance toward good Scrum/Agile practices and increased work efficiency.
- A longer-term role. Therefore, Scrum Masters are usually employed within the organization itself.
AGILE COACH:
- Works at the enterprise level. Simultaneously supports many teams and doesn’t have deep insight into individual team dynamics.
- Establishes a coordination system between teams in the organization.
- Spreads Agile awareness and supports the organization’s Agile transformation.
- Paid 20-30% more than a Scrum Master (if employed by the organization). If contracted, sky is the limit.
- Considered a shorter-term role. Therefore, an Agile Coach is often an external contractor.
Based on the above, one might conclude that the reality of the Agile market dictates that the relationship between Agile Coach and Scrum Master is similar to that between software architect and developer. But is this really the case?
I quote the latest Scrum Guide:
“The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization .”
The distinction between Agile Coach and Scrum Master is largely artificial. Scrum Master cannot operate only at the team level. Their tasks extend across the entire organization. Therefore, a Scrum Master also conducts coaching. Whether this is predominantly at the team or enterprise level depends on their knowledge and experience. The desire is, of course, for all Scrum Masters to eventually become capable of operating at all organizational levels. This is especially important when an organization implements one of the Scaled Agile frameworks. If Scrum Masters then rename themselves to Agile Coaches, it’s irrelevant to the state of Agile in the organization. Though it sounds better on a CV.
WHAT ABOUT DEVELOPERS AND PRODUCT OWNER?
Reality-check
Agile development is based on constant exchange of information and knowledge between stakeholders. An effective tool that prevents the creation of isolated “knowledge silos” is level-up rewarding. This means that the development team is rewarded for achievements as a whole. In Agile organizations, individuals are not rewarded for individual contributions. For this reason, team members are interested in sharing their knowledge, as this increases the productivity of the entire team.
The question that usually comes up at this point in courses is: “ What if we have a team member who’s freeloading off others? “
The answer to this question is simple, but challenging to implement because it requires a mindset change within the organization. If we consider ourselves an Agile organization, it means our development teams are self-organizing. Such teams decide on their own membership. New members can join the team from within the organization (organizational mobility), or teams can independently hire from the external market (with or without HR support).
Before HR starts shouting that “ this isn’t how things work “, since new developers must be planned for in the annual plan – which is irrelevant in practice if the new member will generate profit – let’s ask ourselves this: Is it ethical to take away teams’ right to choose their own members if we reward them as a whole?
And so we return to the team member who’s “freeloading”. If this is the case, other members of the self-organizing team have the right to dismiss them. After all, their own compensation suffers because of them. If the member was drawn from the organization, they can return to their previous position, and if they were hired solely for the project’s needs, they can be dismissed.
In a Scaled Agile environment where multiple teams simultaneously develop the same product, rewarding is done at an even higher level – at the group of teams level. Since spontaneous communication usually occurs within individual teams, in scaled environments, special effort is needed to ensure knowledge and information spread as effectively as possible between the group of teams. We know many tools that can help with this.
(PARTIAL) CONCLUSION
As I was writing it, the article kept getting longer and longer, so I decided to split it into two parts. In the next part, we’ll learn about ten approaches (tools) that teams in a Scaled Agile environment use to effectively share knowledge and information.
