Learn as a Team

This is the presentation I gave at the bbv Techday 2010 – a company internal conference day.

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 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.

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 the new things. Therefore, learning new stuff is motivating. And a motivated team simply performs much better.

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, continuous learning.

Learning itself is a change process. Therefore, I borrowed the ADAPT acronym from Mike Cohn to explain the learning 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.

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.

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. I’ll give you a list of these later on.

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.

This is important to prepare for the next learning step and to lower the Desire hurdle.

The last step in the learning process is to transform the newly acquired knowledge into better productivity and to transform your environment to cope with your personal or team progress.

Transforming the environment means that you or your team passes the new knowledge on to other teams. This is crucial because new ideas can only survive in a non-hostile environment. All of you, who have introduced something new into their companies (Scrum, Test Driven Development), know how hard that can be when everybody else cannot see why this new whatsoever is an improvement.

Learning needs to basic things:

Number one: …

… 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 favorite development tool.

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

The first is …

… retrospectives.

In a retrospective, the team looks back in time. In the Scrum Retrospective, the team looks back at the last 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 the next Sprint.

The second is called …

… 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.

Number two of what is needed for learning is…

… repetition with variance.

The movie Groundhog Day shows this principle perfectly: Whenever Bill Murray awakes in the morning, it is still the same day. He lives through this same day over and over again. Finally, he can break this loop when Andie MacDowell falls in love with him. Until then, he tries to live this day in several ways, always with some variance.

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.

On the following slides, I’m going to show you what we do at bbv Software Services AG to push individual and team learning:

Here you can see an overview of the practices we use to learn.

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.

In Engineering Roundtables, a couple of developers sit together and discuss a technical topic. Examples are

• how do we write good unit tests
• how does the new technology XY work
• how to integrate testing in Scrum Sprints

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.

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.

A Guide can help you to get a deep understanding very quickly.

If you want to understand a domain as deep as possible then you should try to teach the topic to others. When all other resources are used then the only thing remaining is to Learn by Teaching. This practice gives you the deepest possible knowledge on a topic.

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.

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), 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, the first developer takes another look through the changes when explaining and often sees for himself where something went wrong. And second, the reviewer gains understanding of the current state of the code by this know-how transfer.

This is a perfect addition to pair programming for us because we do not develop all our code in pairs.

If you want to push the team knowledge in technical and process skills (Test Driven Development, Clean Code, tool usage, …) 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 behavior. Therefore, they are a perfect environment for a team to learn as a whole.

Once a year and for new Employees, we do a so called boot camps. The photo on the slide is from a boot camp for new employees to learn Scrum and Test Driven Development. They had one week to build a game called Winkeladvokat. The week was split into five Sprints with a single day duration. Therefore, on every day there was a Planning Meeting, Sprint Review and Retrospective. The code was developed using Test Driven Development and all the tools we use in our real project work: continuous integration, StyleCop, FxCop, svn and so on.

After this week, the participants were ready to start in one of our Scrum teams, they learned how we build software and could experiment with the methodology and tools.

Boot camps 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 effectively in a short piece of time (in only one week instead of probably over one year).

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

But if you want a really high-performing, fast learning team then your team needs 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 (ADAPT).

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 a …

… highly motivated team.

And now, multiply the number you had in mind during the first slides – 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 …