Team learning

This is the hand-out of my talk at the Agile Leadership Day in November 2013.

How much faster would your last project have been, if your team knew in the beginning, what it knew at the end of the project? What if your team knew all the technologies and how to use them correctly in the project setup? What if your team knew the domain of the project in detail right from the start of the project? Would they have been twice as fast? Or even faster?

Knowledge is one of the key factors regarding project success.

Your team needs to know the problem domain it wants to solve with the software it builds. The team needs to know the technology and tools it is using. The team needs to understand the process used to achieve the goal and many things more.

Therefore, it is crucial to get a high level of knowledge as fast as possible. The steeper the learning curve, the faster your team gets performing. And of course, if you can start with a higher level in the beginning, this is even better. By acquiring the needed knowledge faster, the team finishes the project earlier.

This is the reason, why team learning is so important when starting a new project.

But there are personal reasons too:

People, especially software developers, like new things. Software developers can get very enthusiastic regarding new technologies and tools.

When a project leader or project owner (Scrum) looks for people to staff her team, then she will surely prefer to get the best people available. Therefore, if you want to be part of the coolest projects, you’d better be good. To get good in anything, it needs learning.

Finally, it just feels great to be with the best. But this doesn’t come for free, being with the best needs continuous improvement and continuous learning.

Learning needs three basic things:

Number one is feedback. Only through feedback, we can make learning visible. Be it the exam you passed in school, or that you noticed that you use now the shortcuts in your favourite development tool.

Let’s have a look at three ways of feedback for teams:

The first is failure. Failure is hard but it forces you to change something and try again.

The second are retrospectives. In a retrospective, the team looks back in time. In the Scrum Retrospective, the team looks back at the Sprint.

Normally, the team identifies the main things or happenings that

• were good and should be done in the future, too
• can be improved in the future
• should just not occur again.

The team uses this feedback to learn how to improve for the next Sprint.

The third kind of feedback is dog feeding. Whenever a team builds something, make them use it themselves.

This is especially important, if your team builds some sort of framework or library. The worst thing to do is to split the developers into a framework group and an application group. The framework group cannot close its feedback cycle because the developers do not use the framework to build an application. This will result with almost 100% certainty in a framework too complex and with missing features.

Only when you use what you build, you have to live with the consequences of your decisions and will learn what works and what doesn’t.

The second thing needed to enable learning is repetition with variance. Evolution introduces into every generation a little change and checks whether it is better or worse. The better survive, the worse don’t.

The same applies when you want to learn for example a practice like Test Driven Development, or how to make good presentations. You should do it over and over again and vary every time a little thing. This way you can optimize what you are doing based on the feedback of each little change. The variance helps to keep teams excited about what they are building, too. Simple repetition without variance gets boring quickly.

The third thing needed for learning is focus. You cannot learn everything at once. You have to focus on few things at a time. My experience tells me that you should keep under three topics for a team. Therefore, keep a backlog of stuff to be learnt and only take a new item when another is established in the team.

Once again, if you want to foster learning, make sure the team meets an environment that provides fast feedback, allows repetition with variance and focus.

There exist a lot of methods to enable team learning. I’ll show you what we tried in our company.

I’ll gather these methods on this diagram. Horizontally, you see whether a practice is good for individual (to the left) or team learning (to the right).

Vertically, the practices are sorted by the depth of knowledge you can acquire with it. On top are the practices providing the most in-depth know-how.

Learning itself is a change process. You go through several phases when learning a new skill. If you want to introduce a learning culture in your organization, you have to find a way to quickly get people through this process.

Before you can learn something new, you need to be aware that there is something out there that can be learned.

This can happen because the new guy in the team talks about this cool tool you don’t know (yet), you go to a conference and hear about new ideas, or you read blogs of some interesting people.

In my company, we have so called technical leaders. Technical leaders have the ability to quickly get themselves through all the phases of the learning process without any external incentives.

Part of their job is it, to teach others. The first step is to make people aware that they do not know everything. This happens through announcements of workshops and courses or by talking with each other.

Just knowing that there is something you don’t know is not enough. You need the desire to learn it.

Every step in learning is an investment. It is hard and needs real effort of the person who is learning.

Therefore, growing desire is often the most critical part in the process of learning and sometimes the hardest part to achieve. Technical leaders support others to overcome this hurdle by showing what they get out from this investment. Maybe work gets easier, more fun or less risky. I’ll get back to this later on.

Once, you or your team knows what and why to learn something, you need to be able to do so.

Sometimes, time is enough. But most times, more is needed: a coach, or a kind of team learning.

We work with Scrum and Scrum provides itself some good opportunities for learning.

When the team talks together with the product owner about the product backlog – the so called product backlog grooming – the team learns a lot about the domain. The product owner explains why something is worth building and what business problem needs to be solved. The product backlog grooming should be done frequently so that a team can suggest better solutions due to better understanding of the business and end user needs.

Every sprint planning meeting gives us the opportunity to learn to plan better. Try to introduce some variance into the repetitive task of planning. This is a good way to improve planning and estimation skills.

In the sprint review, you talk with your stakeholders about what you learned during the sprint. This often leads to new insights on both the stakeholders and team side. And the discussions about the product increment during its demonstration help the team to better understand what has to be built.

Finally, the sprint retrospective is the place to talk about what insights we had during the sprint, what we learned about the way we work and how we could improve it.

The activities in Scrum help the team as a whole to learn about the domain of the project. The frequent discussions with the product owner and stakeholders support the team in acquiring a high level of knowledge in a short time frame.

We use pair programming not only to get better quality in less time. We also use pair programming to transfer know-how between developers.

In a pair programming session, both developers learn from each other: they discuss and find solutions, they see how they use the development tools (yes, this can really by an eye opener), and they get immediate feedback on every action.

Because pair programming happens between two programmers this practice is somewhere in the middle of individual and group learning. But because you go down to the code, the depth of knowledge is very deep.

Whenever a developer in my team wants to commit changes in code to the source code repository then he asks another developer for a Commit Review. In a Commit Review, the developer, who has changed the code, explains these changes to the second developer.

Two things happen here: First, a know-how transfer from the developer to the reviewer. And second, the reviewer provides feedback to the developer. A great opportunity for learning.

This is a perfect addition to pair programming for us because we do not develop all our code in pairs. The depth of knowledge transferred is however somewhat smaller.

If you want to push team knowledge in technical and process skills, like Test Driven Development, Clean Code, tool usage and so on, then Coding Dojos are for you.

In a coding dojo, the team – or a group of developers – sit together in front of a beamer showing what happens on a computer while two developers practice pair programming. The members “watching” can provide inputs to the developing pair.

A coding dojo normally takes 1 to 2 hours.

Coding Dojos push common understanding and common behaviour. Therefore, they are a perfect environment for a team to learn as a whole. You can focus on a specific topic during a coding dojo and the team can acquire a deep knowledge.

In Focus Groups and Workshops individuals with the same interest in a topic meet to discuss. In a Scrum Focus Group, developers, Scrum Master and Product Owners meet to share their experiences and to find solutions to common problems. A focus group helps to boost knowledge over several teams. A workshop is a team internal meeting to increase knowledge on a certain aspect of the project, like architecture, continuous integration process and so on.

This gives the whole group a common understanding of a topic. Therefore, it is a good group learning practice, however the depth of knowledge is limited. Keeping a focus group together over time increases the depth of knowledge and the effect on the whole team.

The members of a book club read a book or blog, or they watch a video together and afterwards discuss about what they learned from it. Hearing about insights of others increases the personal learning effect.

A book club is more about personal learning than team learning and the depth of knowledge from a team perspective is limited.

In our company we have days reserved for learning at the company level. The bbv Techday is an internal conference day, on which we have presentations about what we learned during the year in our projects. This ranges from technology and tools to soft skills and management topics. The bbv Forum is held three times a year and focuses on workshops about topics relevant to larger groups within our company.

The presentations and workshops provide insights into how others are working, but no in depth knowledge. The recurrence of the bbv Forum helps to foster learning as a group.

Under the name bbv Academy, we run courses from 1 to 5 days about topics that we consider basics for our employees. These are things like Test Driven Development, Scrum, Clean Code, working with Legacy Code, Requirements Engineering, Testing, and much more.

The academies cover basics, but whole teams can learn together.

Once a year, we take a whole week off and focus completely on learning. Topics varied from learning Scrum when we introduced Scrum in our company to role specific topics like architecture training.

Education weeks cost a lot of money but provide great team learning on a very high level of knowledge and boost common understanding and team efficiency and effectiveness in a short time frame (in only one week instead of probably over one year of working in a real project).

There will always be the need for personal learning. Especially the technical leaders will need a lot of individual learning.

With classical Individual Learning – like going to conferences, reading books and blogs (thanks for reading my blog by the way) – you can get a deep learning effect but the team benefits little directly.

We also use individual annual goals and Sprint goals to push individual learning.

A Sprint goal is a little thing you pay attention to during a Sprint to make your daily work more efficient and effective: learning Visual Studio shortcuts, writing readable methods or something like that.

After learning something new, it is important to celebrate.

This may be that you look back at the times before and pat yourself on the shoulder or a team celebration that the team has learned something new.

Promotion of learning successes is very important to get other people onto their learning path. People get aware that others have a new skill or insight. It makes them aware. And seeing all the happy faces makes the others wanting to share this success and therefore increases their desire to learn the same thing. Promotion is a strong positive feedback loop to awareness and desire. I often hear that developers are not interested in learning something new. But that is probably because no one shows and tells them what their gain is.

An easy way to promote learning successes is to visualize them. A team may put sticky notes onto a wall about what they learned. After a year, you get an impressing list of things the team learned. Others may take a look at get inspired to learn something, too.

Or you even go public – like we do with our posters.

At least, you should talk about it to your team members and to other employees.

We Swiss are famous and laughed at for our Apéro culture. But never underestimate its power. You can do a lot of promotion there.

Of course, you won’t discuss technical details at an Apéro, but people are in a good mood and a learning initiative is often started there.

The last step in the learning process is to transfer the newly acquired knowledge to other people. One individual teaching someone else, or a whole team helping another team.

If you want to understand a domain as deeply as possible, you should try to teach the topic to others. You’ll get challenged by questions and enforce your knowledge by explaining.

This practice gives you the deepest possible knowledge on a topic.

The transfer phase is used to enable others to learn. Your organization teaches itself. This scales also very well, which is important if you want learning to happen throughout a whole company.

This is the summary of all learning variants I showed you.

There are even more on it.

A pet projects is a project that is initiated by an individual or a team to learn a certain technology or method.

In brown bag meetings, people meet during lunch hour to watch a presentation. This is the low cost, low focus variant in case you cannot do anything else on this slide.

Not every employee can do all of these activities. That would simply take too much time. But every employee can choose from all these activities what matches best for him or her.

Learning should take place as much as possible in the project the employee is working in. That’s because we learn to be better in the project. But we also have time outside the project for employees to learn things that are not currently used by their projects. Either to get better for a next project or to get know-how about something that might be useful to the project. Finally, we expect from our employees that they give a bit of their spare time to keep up with the technology they are working with. But only a bit.

I have shown you what it needs for team learning and some practices we use to boost it.

To sum everything up, there are two main insights we had while establishing a culture of learning in our company.

If you want high-performing, fast learning teams, your teams need to develop a challenger spirit. Every team member is eager to learn from all others and challenges the team with new inputs. This gets you quickly through the awareness and desire steps in the learning process.

Kick off the learning spiral by supporting individuals willing to learn for themselves and support them to become technical leaders. Technical leaders, who help others to get through the learning phases quickly. Put a lot of effort into promotion of learning successes and the learning spiral gets spinning faster and faster.

Finally, what I learned from all the effort we put into individual and team learning is that providing the environment for a good learning culture results in highly motivated teams.

And now, multiply the number you had in mind during the first slide – when I asked you how much faster your last project would have been when your team had known from the start what it knew in the end – with the factor a highly motivated team is more productive than a “normal” team. I leave you with that thought …

Thanks for reading. If you have any feedback, please write a comment.