The Scrum Master as agile learning coach

• How can you as a Scrum Master concretely support teams in their learning during sprints?
• What distinguishes good team and individual learning stories?
• What is the added value of a role understanding as Scrum Master and agile learning coach?

The explanations extend and deepen the considerations of the article Successful with learning stories in the backlog, which is about the support of a customer and its “Team Zero” as well as the anchoring of learning in Scrum by means of learning stories. Learning stories are managed in the backlog in the same way as user stories.

Heiko’s story

Let’s take another look at “Team Zero”, which we are privileged to support as an IT service provider. Since individual team members – including the product owner – are English-speaking, the working language has been English since the kickoff. Now it turns out that the team needs to build up basic knowledge in the area of test automation. Quickly, the team makes progress, as many technical articles and publications on test automation are available in English.

After a retrospective, a participant – let’s call him “Heiko” – approached our Scrum Master. Heiko, who had already been working in the company as a software developer for several years, used to have English lessons at school. He didn’t really enjoy the language and the lessons back then. After that, however, his language practice was reduced to a minimum.

“Speaking English is just not my thing,” Heiko began, which visibly cost him a lot of effort, “and now these technical articles – honestly, I’m having a hard time with that. I also ask myself whether I understand everything correctly in Backlog Refinement or Sprint Planning, for example, but I don’t always want to ask questions and stop everyone.”

The fact that Heiko had addressed the topic so openly was not only courageous, but also very important and ultimately a gift for the entire team. Only in this way was our Scrum Master able to find out what he perceived as challenges or excessive demands in his daily work. And only in this way could she determine his learning needs together with him, plan personal learning goals and derive the appropriate learning steps from them, which would ultimately make him a supporting pillar in Team Zero. Together with Heiko, she formulated personal learning goals, which we call “individual learning goals”; the Scrum Master role was thus expanded to include the task of agile learning coach.

Agile learning – individually and in personal coaching

What Heiko and the Scrum Master developed as individual steps was a combination of text and vocabulary learning in self-study and the practical language exercise in tandem. For the self-study, we asked a colleague who was very well versed in the subject and language to take on the role of a mentor for Heiko. He could discuss questions about English-language technical articles on test automation with her and also clarify vocabulary.

For language practice, a native speaker was found in the company who met with Heiko for an hour a week for an English-German language tandem. In addition to a little help that all language tandems receive, both received short thematic suggestions for their meetings. For example, Heiko was able to practise exchanges in planning or refinement meetings in short role-plays.

The first meeting between Heiko and our Scrum Master was followed by regular meetings in which both reflected on the progress, adjusted the goals and explored further materials and topics.

Agile learning – synchronised and collaborative in the team

The procedure was different in the aforementioned topic area of “test automation”. Here it quickly became clear to the Scrum Master in the retrospectives that presumably almost all team members had a substantial need to learn. But she wanted to know exactly and therefore looked at the previous knowledge and the current status in the individual discussions:

• What do the team members bring with them?
• What are they confident about / what are they not?
• What are open questions?

At the same time, it was important for her to identify necessary steps in team development:

• Where is assistance conceivable?
• Which – especially collaborative – learning formats are possible and useful?
• What resources are available?

With the results of the individual discussions, our Scrum Master went into a three-way meeting with the project’s Product Owner and an expert in test automation who was not involved. Together, they mapped out the horizon of technical knowledge the team would need to successfully implement the project; in other words, the team’s “learning scope” for prototyping was defined.

Now that it was clear where the individual team members stood and where the journey should go, the Scrum Master presented her findings to the assembled team. The most important questions were now:

• How do we tackle this challenge together?
• How do we synchronise learning with our product tasks?
• How can we support each other?

The answer to these three questions was: With “team learning stories”.

Formulating team learning stories in a goal-oriented way

The Product Owner and Scrum Master worked together to create the team learning stories. To give an example: Among other things, the team had to make a decision about which test framework should be used in the future. Two alternatives A and B were available. The learning story was: “As a team, we can assess the advantages and disadvantages of alternatives A and B in order to then make an informed decision about which solution is better for our project.”

The similarity to the pattern of sentences in a user story is recognisable. And similar to user stories, acceptance criteria were also defined here, e.g. “I can name the aspects of the documentation of product XY that are relevant for our project” or “I have summarised the essential advantages of the two alternatives in a bullet-point list”.

But why acceptance criteria in learning? Acceptance criteria in learning stories give learners orientation – especially in a new subject area – and also allow them to determine whether they are successful in their implementation. In addition (and unlike in user stories), learning story acceptance criteria can already point to the solution space of a learning objective, e.g. by pointing to sources of information or prescribing a certain procedure (e.g. the reference to certain documentation above).

At the same time, learning stories can open up the space for self-organised and autonomous learning, as the team is left to work on the learning stories. This can be seen, among other things, in the Definition of Done – more on this in a moment.

From refinement to planning to review

The team learning stories – like other backlog items – were discussed with the team in the refinement. The Scrum Master acted as an advocate for the learning stories so that they were given adequate priority in the next planning and could be appreciated. This is necessary because learning stories, like technical tasks, have the challenge of not adding immediate value to the product.

The team could also ask questions of understanding and make their own suggestions. A good refinement therefore helps everyone in the Scrum team to establish a common understanding of why, for what, in what depth and with what benefit for the product or the team something should be learned within the sprint. For this reason, we also excluded individual learning stories from refinement and planning. Accordingly, each team member had a fixed learning time budget per week, which he or she could freely use for the individual learning stories.

As a result, there was an organic alternation between iterations that were more learning-intensive (such as the decision-making between alternative A and B) and those in which the focus was on product development (e.g. setting up the test infrastructure).

Finally, in planning, the Product Owner presented the team learning stories along with the other backlog items. He was responsible for prioritising the items and the learning stories, because he had to take into account that correspondingly less was developed on the product side. Then the team estimated in the form of the Fibonacci sequence and the learning story passed to the team’s ownership.

The review was also not much different from a “normal” review, with the main difference that the team learning stories were not approved by the product owner, but by the Scrum Master. As in the planning phase, where she had no technical expertise, she brought an expert on board who checked the acceptance criteria with the team members and was available for technical sparring.

The Definition of Done for team learning stories

Of course, a Definition of Done was also developed in the team for the team learning stories. This was important because not all learning stories were worked on by everyone in parallel or to the same extent, but the results should be collectively usable.

The team agreed on five steps that could be adapted for individual learning stories. Thus, a learning story was “done” when

1. a selection of materials was made (e.g. books, documents, tutorials, possibly with the help of an expert),
2. exercises were designed to apply new knowledge and skills in practice,
3. material and exercises have been worked on by the relevant learners,
4. the findings were documented in a wiki-like glossary, and
5. were presented and discussed in the whole team.

It is with the sharing and securing of learning that learning becomes sustainable and even new team members can benefit from the collections thus created.

From Scrum Master to agile learning coach

As I hope has become clear, learning stories are not a secret weapon that once introduced become a no-brainer. If the Scrum Master role is responsible for eliminating team impediments and there is an essential learning need in a team that becomes an impediment, then it is inevitable that a Scrum Master must also be committed to the topic of learning.

Learning stories are an effective tool here, but the added value – as is so often the case – only comes from the interaction of the team members. We are convinced that a Scrum Master who sees himself as an agile learning coach always creates added value by, among other things

by promoting an open learning culture, e.g. by personally accompanying learners like Heiko and having a learning contact person.
by making the indirect value of team learning goals for the product visible and discussable and thus finding a reflection in the backlog via the product owner.
by using well-edited learning stories to ensure that learning is goal-oriented, motivating and sustainable.

The good thing about this approach is that as a Scrum Master you can try out a lot of it yourself with your team in the next sprint. Some things will certainly be easier if you know more about learning objectives, practise and reflect on learning guidance beforehand or have an exchange with like-minded people.

Notes:

If you like to learn more about QualityMinds and the learning approach, or if you like to discuss your experiences with the authors Eva Dirr-Bubik, Dr. Vera Gehlen-Baum and Dr. Manuel Illi, please ceck https://qualityminds.com/de/qm-portfolio/quality-learning/ out.

From QualityMinds you can find more articles in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.