Successful with learning stories in the backlog

Agile learning in Scrum teams.

Talking about Scrum teams sometimes gives the impression that many have a group of Avengers Super Heroes in mind. The experienced reality then usually looks different, especially if you ask the members of Scrum teams. But both are important: An ideal picture gives orientation and an honest picture of reality points the way to a positive development – as long as you focus on the strengths in the team. In our article we would like to use a practical example to show how learning with the help of learning stories made a young Scrum Team a successful team.

Simply inseparable: agility, quality and learning

When it comes to agile software development, learning is one of the most important and valuable topics – clearly visible in the two keywords “inspect and adapt”, among others. Since we at QualityMinds, as an IT service provider with a focus on software quality, are allowed to accompany many different projects, teams and transformations, we see this necessity every day.

Those who understand software quality comprehensively recognise that quality begins with the attitude, knowledge and skills of the people who plan, develop and test it. Quality can neither be “tested” into a product shortly before the roll out, nor does a “high performing team” fall from the sky. From our point of view, learning in the agile world is an essential success factor. Last year we gave an insight into our approach of agile learning and agile learning coaching on an individual level here in the t2informatik Blog. But learning also works very well in Scrum teams.

The Challenge: Team Zero

In agile teams it is important to initiate learning through regular feedback loops, e.g. to gradually adapt the use of agile practices. In our experience, transformation and change processes are always and above all learning processes. It is best to see mistakes as learning opportunities – as chances to develop oneself, the team and the product. So much for theory.

In practice, however, no Scrum team is one of these high performing teams from the beginning, which we often see in blog articles or in literature as ideal. This is perfectly ok, but has to be taken into account to avoid excessive expectations and frustration.

We were able to gain this experience some time ago by supporting a client team. We want to call it “Team Zero” here, because it should be the first team in the company that works agilely according to Scrum. For this purpose it was newly assembled and assigned the task to build a prototype for test automation of a new application that was developed in parallel in other, still classic teams.

The composition of Team Zero was heterogeneous: One part was very young and had little experience in software development. The other part had many years of experience in software development, but was inexperienced in test automation. From our side there was a developer, a Scrum Master and a product owner on board.

The management gave the team and us, as external support, a lot of freedom to work together. But even the first sprints were not free of challenges. Again and again it happened that routine tasks became show stoppers due to lack of experience. Then again, user stories that seemed harmless to the team in planning were completely misjudged due to lack of expertise, so that the sprint goal was not achieved.

We had experienced something similar in the accompaniment of agile transformations before. However, Team Zero also had a counterproductive dynamic known as social loafing or the Ringelmann effect: Instead of the team working together and together on tasks and helping each other out where necessary, individuals began to withdraw and retreat into a comfort zone of non-competence: “I can’t do that, so I don’t have to work on it!”.

Within the team, social loafing has a negative reinforcing effect. This threatened not only to fail the implementation of the prototype, but also the piloting of agile cooperation. So it was high time to look at what the causes were and what needed to be done.

Inspect and Adapt: Learning!

One of the many advantages of the Scrum framework is, as is well known, that problems can be made visible quickly – as in Team Zero. Already after two retrospectives it was clear that the team as a whole, but also most of the members personally, still had a lot to learn: The main thing was to build up professionalism and corresponding routines. In addition, they also needed social skills for agile teamwork as well as language skills, since the working language was English due to the international cast.

Thanks to our experience with agile learning, we were able to quickly come up with a solution that anchored learning firmly in Team Zero’s sprint cycle. On the one hand, we used agile principles that had proven themselves in the learning context – for example, the fifth principle of the Agile Manifesto (“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”). Learning should therefore be collaborative and as far as possible self-organised.

On the other hand, we drew on results from research on teaching-learning and organisational development, such as the seven dimensions of a learning organisation (including “continious learning” or “empowerment”, Marsick & Watkins: Demonstrating the Value of an organisation’s Learning Culture – The Dimensions of the Learning organisation Questionnaire. ADHR 1/2003). Learning should take place in a learner-friendly and supportive enabling environment, ideally integrated into the daily work of the team.

The solution: creating value with learning stories

The core idea behind the implementation was to handle the learning needs in Team Zero in the same way that some teams deal with the “technical debt” of an application.

This term is used to describe the additional and retrospective effort required to improve very quickly and poorly written software. The removal of technical debt is not immediately productive, because it does not directly lead to a new element of working software. It is therefore sometimes difficult to communicate to management and/or specialist departments. However, indirectly and in the medium or long term, these improvements have a decisive influence on value creation.

Even learning effort does not directly result in a new increment of functioning software, but in the medium/long term it creates measurable and visible added value – both for the team and for the product. Just as with product improvements, it is important that learning takes place and that resources (especially time) are made available for it. Fortunately, in the case of Team Zero, the responsible managers recognised this and gave the necessary freedom. We were thus able to implement an appropriate solution with the following five aspects:

1. Making learning the prioritised topic: The aspect of learning was addressed openly with the entire Team Zero as well as the departmental managers and a team learning vision was created. This vision resulted in overarching learning topics and task specific learning fields (e.g. linguistic confidence or professionalism in the field of test automation).
2. Mapping and considering learning needs in the backlog: Since learning is also characterised by the aspects of time, complexity and risk, we created epics in the product backlog for “team improvement”. Because what is written in the backlog is regularly taken into account.
3. Plan learning goals as “team learning stories”: In discussions with the team (e.g. in the reviews) but also in individual agreements, we have from then on examined in detail whether and which knowledge / skills were necessary in Team Zero, but not yet available. We then derived learning goals from the observations and included them as “team learning stories” in the planning – just like user stories – in the sprint backlog (e.g. knowledge about interface testing).
4. Specifying and implementing them in “individual learning stories”: In addition, individual team members were shown to have individual learning goals. In a personal conversation with the Scrum Master, individual learning goals were specified as individual learning stories and the implementation was planned.
5. Collaborative learning in a sprint: Self-organised, collaborative learning became the key to implementing the learning stories. Of course, there were also self-learning phases in which team members researched, read and tried things out for themselves. But the motto was always: Together we can move forward. In order for this to be successful, team learning stories were naturally worked on during sprint working hours.

The reasoning behind learning stories in the form described is quite simple: if you set yourself the goal of creating value, you must also ask yourself who should create this value from which source. Learning stories are an investment in people and their skills. Do learning stories automatically lead to better products? Not always! However, if implemented correctly, they do have great potential to do so in any case. And vice versa, not investing in learning and then expecting teams like Team Zero to transform themselves into a high performing team was and is no solution.

The practical implementation: ACC, DoD, acceptance and learning coaching

The use of learning stories also raised practical questions, such as: Who formulates learning stories? When are they satisfactorily completed? Who takes them down? In answering these questions, it was helpful that we at QualityMinds can draw on both our many years of experience in agile software development and our expertise in teaching-learning research.

The impulse for agile learning in Team Zero came from our Scrum Master, who has experience in formulating learning goals. She not only convinced the product owner of the new approach, but also formulated the learning stories for the next sprint. The Product Owner read these critically and then included them in the Product Backlog.

The Product Owner thus had an important corrective function: He checked the sense, necessity and scope of the learning stories and prioritized them in relation to the backlog items. In this context the exchange between Scrum Master and Product Owner was especially important. This clarified why and to what extent there was a learning effort and how this was linked to other items or the work in the team. At first the idea was to set up a dual track board with one lane for users and one for learning stories. But because of the clarity and above all a clear prioritisation we decided against it. The Scrum Master, in turn, took on additional facets of an agile learning coach, who accompanies team members on their learning journey.

For each learning story she defined – similar to user stories – acceptance criteria, which were professionally coordinated with experts in each individual case. These criteria had the function of giving the learners orientation in the learning process on the one hand, and on the other hand to name observable criteria by which a successful completion became visible: e.g. “I can explain the advantages of API tests.”.

With Team Zero, a Definition of Done for team learning stories was also developed, which was binding for everyone and in which the sustainability of the work done played a major role. For example, an essential part of the DoD was to discuss important findings within the team and then record them in a wiki.

Team learning stories were valued in planning just like user stories, and in the course of this the responsibility was also clarified (since some learning stories only concerned individual team members).

The review of a learning story took place in different ways, e.g. in the form of a small overview for all other team members or in the form of short impulse presentations. The important thing here was to make what was learned visible and usable for the team as a whole.

A success: social learning instead of social loafing

Team Zero reflected on successes and obstacles in learning intensively in the retrospectives. The self-development and learning competence in the team, the metacognitive skills and the motivation of each team member grew very quickly. And this was probably the most important success that came about through the introduction of agile learning. Because the positive experience of both individual and collective effectiveness in learning became a universal recipe for success in dealing with new challenges.

Even if there was a lot of friction and long discussions in the beginning: Tangible learning successes were achieved after only three to four weeks. And at the end of the pilot phase, the prototype for test automation was completed.

Success factors for working with learning stories in Scrum teams

For learning to work in a Scrum team, certain basic conditions must be given and stakeholders must support the project.

• The management floor: They have to recognise that learning and the further development of the team is equal to the further development of the product. The provision of resources, trust in the employees and a positive error culture are indispensable here.
• The team: It must be open to change and actively integrate learning into its own work. The admission of not (yet) being able to do something should be freely expressed within the protected framework of the team. A common understanding of team responsibility and goal is a basic requirement.
• The Product Owner: He must recognise that the value added in the team (= learning) also directly represents value added for the product. Working with learning stories can be an important instrument of the Product Owner to illustrate this aspect of Scrum, especially for young and less experienced teams. Therefore the Product Owner should be open for the preparatory work on learning stories and for their equal placement in the backlog. He may have to accept smaller increments at the end of the sprint for the benefit of team development.
• The Scrum Master: He has to be on the same level as the Product Owner and trust in his assessment. At the same time he should challenge the team and the Product Owner in a positive sense. He also has to recognise the importance and added value of social learning for the team. It helps if the Scrum Master is familiar with the topic of learning, e.g. through training as an agile learning coach. He proactively supports the team in building up a learning culture, in formulating learning stories/goals and in implementing them (e.g. through a suitable DoD or reflection in the retros).

Even though learning stories cannot turn a Scrum team into an Avengers team overnight, it was an important and decisive step on the way to success. The members of Team Zero eventually became pioneers and multipliers in terms of agility, Scrum and learning in their own company. They were distributed among different teams, which in turn started to work according to Scrum.

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 contact https://qualityminds.com/de/qm-portfolio/quality-learning/.

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.