Learn Better Together

Learning is important to us in software development. What we do for a living is solve problems with software. In order to be able to do our jobs successfully we need to be able to learn: to learn all about the problems we are solving, and to learn different techniques for solving problems, and to learn how to use the tools we need to build solutions.

In our field we don’t solve problems alone, either. Most of us work on a team, and that means we are solving problems collaboratively, which means a lot of the time we are learning together.

As professionals, it is essential to know how to learn and build techniques for learning efficiently. It is equally important to understand how we learn as teams and to build techniques to improve group learning. That’s what I want to talk to you about today.

One of the first questions for any new project is “how long is this going to take?” What determines how long a project takes to complete?

There’s a great thought experiment this comes from Ashley Johnson that helps us see where the time goes:

Think of a recent significant project that your team completed. How long did it take, end to end? Now imagine as soon as you were done you had to immediately do the same project again, all copies of the source code were lost. If you had the same team, the same requirements, the same everything. How long would it take you the second time, to complete the project? Think about that now. If you were to express that difference in terms of a percentage what would it be? The same, 100%? Faster, 80%? 50%? 20%?

The responses to this thought experiment tend to be anywhere from one quarter to three quarters of the time. In one article I found, the authors put the range at 30–80%. Why would it be so much faster the second time? What do we have the second time that we don’t have the first? We learned.

That means that maybe 20–70% of project time (the first time through) is spent on learning.

According to the theory of constraints a system (like a manufacturing plant) can’t move faster than the slowest step in the workflow, the bottleneck.

If you accept that software development can be compared to manufacturing, then it makes sense to identify our bottlenecks and focus on making those more efficient, so that we can make the whole system more productive.
Even if you don’t accept the manufacturing metaphor it’s clear that learning is something we spend a lot of time doing, and as craftspeople we should be seeking to do it better. If we improve how we learn, we might be able to produce better software more efficiently.

How We Learn

So how do we learn? It all starts with active memory, what you can fit in your head right now. Your brain can hold about seven bits of data in active memory at once before you start forgetting things. That’s known as Miller’s Law.

FRTSAASCIIUSCBS

What if I asked you to to learn this string of 15 letters, to memorize it? Could you?

FRT SAA SCI IUS CBS

How about now? It’s the same number of letters, but now instead of 15 units there are only five. This is probably still going to be a challenge

FR TSA ASCII US CBS

How about now? I bet you can now, but why? It’s the same number of letters, and it’s still in the same number of groups. But now those five chunks each mean something to you: FR — France, TSA, ASCII, US, CBS

Learning starts with those small chunks that you can fit into your active memory, but solidifies by building connections and grouping information together. Connecting new pieces of information with things you already know is how you remember things, which is how you learn. This connected information takes up less space in your active memory. Which means you can think about, understand and solve larger, more complex problems.

But like we saw with the string divided into five arbitrary chunks, it’s not enough to group information together — the bits of information and their connections have to be meaningful. And they have to be meaningful to both of us if I am going to be able to use them to efficiently share information with you.

In this way, learning is inherently social. Our shared language and our understanding of common building blocks makes all knowledge transfer possible. Transferring knowledge makes collaborative problem solving possible.

Learning Together Pays Off

We can’t avoid the social aspect of learning, but in a team setting, optimizing how you learn together has great benefits.

A study of 50,000 agile teams done by Rally found that teams with members that stayed the same over the course of a year were more productive, with output twice as high as teams that varied by 50% or more. That’s double the productivity simply for staying together. Why?

When the team members change, there’s learning to do. The new team member needs to learn the ropes and the team as a whole needs to learn how to collaborate all over again.

But stable teams, teams who have learned how to work together, and how to learn together, are the most productive teams of all.

The learning that happens as a team during a project is greater than what individuals would learn working separately. Teams naturally develop a shared vocabulary for the domain that they work in, which makes communication and collaboration more efficient. Learning in a group can also accelerate individual learning because we all benefit by teaching each other and considering each other’s questions.

But it’s the learning how to learn together that leads to increased productivity on all future projects.

This is what that looks like. Self-organizing teams, or teams that are free to learn to organize themselves and their work, initially tend to underperform but then dramatically outperform more hierarchical teams with less autonomy. This is from Ashley Johnson’s excellent talk on “High Performance Virtual Teams”.

I’ve had the privilege of being a member of more than one highly productive team in my career. It’s thrilling to be at work together, when you can almost guess what your coworker is going to say about your factoring. When you can design a massive, complex system around a whiteboard and ship it to production in an incredibly short time. The benefits to learning how to learn together go beyond shipping software. Solving problems is what most of us got into this industry to do. It’s fun. Learning to learn as a team unlocks completely new levels of potential for problem solving.

Learn Better Together

Great teams do form organically and they learn how to learn together on their own. But I think that we can do more to foster this ability in teams.
To make it more likely that more of our teams reach this increased level of productivity. So let’s talk about how teams often approach learning and how we can do better.

I am going to frame this in terms of the three kinds of things that we typically need to learn: processes, tools, and business contexts.

Learning a New Process

One of the things I’ve had to learn with a group several times in my career is how to transition to a new software development process, like scrum. When there’s budget available this is typically done by sending everyone off to a formal class or bringing in a coach to help the group learn and practice the new process.

Formal classroom-based training has many advantages. For one, this is protected learning time, that’s time taken out of the typical working schedule and set aside for learning together. By sending the team to a class the organization has clearly made learning a priority. Also, if the team is sent together they can build some shared understanding and vocabulary around the new process.

There are some downsides to classroom based learning. Classroom learning isn’t effective for everyone — not everyone is going to be able to absorb and retain knowledge gained in this format. Formal training also can favor theoretical knowledge over active knowledge. By active knowledge I mean the information and practical skills that we regularly use at our jobs. If activities are included in classroom learning they are often junior versions of the kind of problems we face on our projects, which is great when you are getting started, but there’s a lot of work to do to apply this junior learning to the complex and messy challenges back to the office when the class is over.

In my experience, the more effective means of helping a team learn a new process is to bring in a coach to work with the team in their environment, to teach the concepts and processes and immediately reinforce them in day to day operations.

Once I was at a company so small and lean that this wasn’t an option, but we needed process improvement. My challenge was to help the team (or in this case the whole tiny company) learn a new way of working together. So I pulled from my experience working in agile teams, specifically how we iterate and reflect to continuously learn and improve.

To start I made sure that our pain points were clear, we all needed to understand what we wanted to learn to do together. We agreed to trying specific new processes to address those pain points. We set up the expectation that we would meet quarterly to reflect on how it was going and update our process as needed.

With this simple iterative model we learned a new process together. We were able to get more done as a company because of this improvement, and because we learned to do this together we could continue to adapt to changing circumstances. In that way, we didn’t just learn a new process, we learned how to learn a new process together.

Reflection and feedback are essential to learning. Whatever learning techniques you use as a team, make sure that you take the time to check in on what you have learned and how you are going.

Making sure the learning is immediately applied by the team is another kind of feedback. Applying what you have learned to your everyday work is the best test of how much you have absorbed.

When learning a new process together, I encourage teams to have a regular touchpoint to reflect on how they are progressing.
The more feedback the better that learning will be.

Learning a New Tool

Another constant need in software development is learning new tools, like a new framework or language. When this comes up, it’s common to send individuals or teams to formal classes, online classes, or to buy them book. Or sometimes we just jump into a project and read the docs and stackoverflow posts as you go along, learning about the new framework or whatever at the same time as you build out production code.

I’ve already discussed the advantages and limitations of formal classroom based learning.

These other common practices, like buying a book, or diving in and learning as you go have similarly limited effectiveness for group learning. These are both examples of learning without protected time. In my experience, you are probably going to spend more time than you planned with these techniques, because learning as you go is very unpredictable. You can argue that you are learning just as much as you need, but you also run the risk of not really learning at all, certainly not as a group, which means the next time your team uses the same tool you won’t be going much faster.

Another example of learning outside of protected team time is brownbag sessions.

Brownbag sessions are informal learning meetings, usually held over the lunch hour (hence the name brownbag, as in the brown paper bag that your lunch is in). Ideally these are self-organized by the participants and the content is useful for a current work, but also interesting to you as individuals.

Brownbag sessions are controversial when used by management as a way to squeeze learning time into the schedule without adding to the calendar duration of the project. This can backfire as a mandated meeting because humans need breaks during the day, and they might not be able to absorb new information if they are there against their will for something they aren’t motivated to learn.

I don’t recommend that team leads organize project-critical learning as brownbags. The disadvantages are that if they are optional, everyone may not choose to be included, which means you won’t be building full team knowledge. Also, if they are self-organized, then they may not exactly align with business needs. If a team member is interested in organizing one, the company might benefit from encouraging them by making space for the meeting and maybe even buying lunch.

If brownbags aren’t ideal for project-critical team learning, what else can you do?

I have found a useful practice for team learning in a format inspired by hackathons.

One time, my organization was moving toward a new framework that none of us knew. We had several projects lined up and so we all needed to learn it. We had a small budget, enough to send some of us to a training class, but we wanted to include everyone, and we wanted our learning to be immediately useful on our projects.

What we did instead of training classes was to spend our money on hiring a local expert to join our team for a special multi-day internal hackathon. We booked a room in another building and blocked off our calendars. We took our first upcoming project and broke it up into interesting pieces, and formed small groups of 2–3. During the hackathon while we worked our expert would come around and pair as needed, when common challenges emerged we would all stop for a group lesson from our expert. At the end of the event we had not only learned the fundamentals of the new framework, but we also had a shared understanding of how it works, on top of that our first project was well underway.

This was an ideal group learning experience for my team. We had a clear goal, our learning was immediately applied, our learning time was protected, everyone was included, and at the end of each day we reflected on our challenges and success.

Software development teams are often around 5–12 people, which works well. When it comes to group learning, researchers in cooperative learning have found that the ideal size and composition of a group for learning is 3–4 people with mixed abilities.

Learning together doesn’t always have to mean all 12 people learning the same thing at the same time. As with my hackathon, it can work incredibly well to break the team down further than usual when focused on learning activities.

Learning a New Context

The third and arguably most important thing that we need to learn for each new project is what problem we are trying to solve. That often means learning about a new business context or industry.

One of the best tools for learning about a new problem and how we might solve it is a spike. Spikes are timeboxed work planned into a sprint for the purpose of learning something ahead of doing actual production work. Activities in a spike might include research, design and prototyping, but not producing production code.

Spikes are protected learning time with a clearly stated goal, and ideally that learning is immediately applied in the next sprint. Spikes are usually done as individual work, which is not group learning, but they can include everyone in the form of a spike review at the end.

It’s that sharing of knowledge at the end that is most challenging and most important. On my best teams we have used many different formats for spike review: a detailed pull request of throw-away code, a wiki document, or a formal presentation to the team.

One of the fastest ways I learned about and taught a new business domain was through what I called a pair exchange program. This was kind of a radical experiment, where an old colleague and I got permission to each take a day and work at the other person’s company as a pair. This was inspired by the practice of pair programming, which is actually a wonderful tool for group learning one pair at a time. In pair programming two developers work on the same code at the same machine at the same time. They take turns being the “driver” at the keyboard and the navigator paying attention to the bigger picture.

When visiting the other company we got a quick intro to the project and then sat down to pair on the bugs and features the other person had lined up to do anyway. The host got the benefit of a fresh pair of eyes on their code and processes from a seasoned peer, and the visitor gained new ideas, a new perspective on familiar problems, and an understanding of a completely new domain. Teaching my friend about the business requirements of my project at the time helped me understand it better.

Now, this practice won’t work for everyone. It helped that my old colleague and I were not only experienced with pair programming, but also at pairing with each other. We had spent a year in a previous company learning how to learn together, so our pair exchange days were probably extra productive because we knew how to anticipate each other’s questions and share knowledge efficiently.

I still like to share this idea, though because it was a very successful learning experiment: the learning time was protected (or at least sanctioned) by our companies, what we learned was immediately applied to what we were working on, and at the end of each round we took a break to reflect on what we learned and how it went, and what we might like to do differently the next time.

Teaching has the benefit of reinforcing learning for the individual. The questions and comments from the team at the end of a spike or any learning activity benefit everyone involved.

Learning how to transfer new knowledge from an individual to the rest of the team is a critical skill to practice and master.

Learning is Hard

Learning is hard. Change is hard. I’m trying to convince you that it’s worth the effort to find better ways of learning together. There isn’t one solution that is going to work for every person and every team. You are going to have to try different things and see what works for you.

When forced into new, collaborative learning practices, academics have found that people can go through all of the stages typically associated with trauma and grief: Shock, Denial, Strong emotions, Resistance and withdrawal, Surrender and acceptance, Struggle and exploration, Return of confidence, Integration and success.

Resistance to change is human nature. Expect that there will be challenges when trying to introduce new learning practices to your team, and to be ready to help work through them.

• Resistance from inside the team is usually solvable if everyone is invested in becoming a high performing team. The key is to convince them that this technique can help them get there.
• Resistance from outside the team is a little trickier, and this often comes up when trying to get protected learning time in the schedule when there wasn’t any before. The best argument that I have is that learning is an investment in future productivity, and your company will pay the price of learning one way or another.

Even if you don’t face resistance, learning experiments can hit other kinds of obstacles:

• Sometimes your team will flounder with a new practice — in those cases I find it helps to check that everyone understands what the goal is, to try to tackle a simpler challenge, and if that doesn’t work then look for a different approach.
• Other times it can seem like the team is rushing through learning. If that’s the case, seek feedback on what they have learned by applying the learning and reflecting. If the team has what they need, then there’s no reason to hold them back on principle.

Team learning, just like all collaboration, can seem more challenging when people are not co-located. I’m remote from my team in my current role. I do brownbag sessions, retrospectives and spike reviews all remotely. Remote learning is challenging because remote communication is challenging, and learning is inherently social. When you find the right tools for synchronous and asynchronous communication, and for communicating visual ideas as well as code and conversation, you will find that many of the good principles that you know from learning in the same room can apply to your remote team learning as well.

Learn as a Team

I hope that I have convinced you that thinking about and improving our learning techniques as teams is a worthwhile investment in our productivity.

How does your team practice learning together? It may be possible to improve your team’s ability to learn together, and boost your productivity, by varying your approach. You could try spikes, or browbags, or hackathons, or pair exchange programs, or you can come up with a new idea to try. When you set out to design and attempt a new learning technique together I recommend these general practices:

• Clarify goals for the learning activity. Make sure everyone is in alignment about what you need to learn and why
• Apply what you have learned together immediately — the sooner you use your new knowledge, the better it is going to stick
• Protect your learning time — if you are in a position to do so, make learning and developing new group learning techniques an explicit priority and create time for it in your team’s schedule. You will learn one way or another, but creating time for it can improve your learning efficiency.
• Include everyone — learning is social and for the team to build active knowledge together they need to learn together.
• Iterate and reflect — no single learning technique is going to work for every person or every team. It’s beneficial to take time to reflect on our learning practices: what is working well and what could be better, and iterate to improve.

Learning is essential to our craft. I encourage you to seek out practices that work best for your team, to unlock happiness and productivity by learning better together.