Even your busiest engineers have the time to learn.

Many teams have little time and few resources for working on technical skills and struggle to build a culture of learning, even when their organizations recognize the value of it. I would like to share a technique that will enable you to start small – very small – and build a culture of learning without having to make a case for dedicated time.

My background

I have worked as a team lead, consultant, and technical coach, and I’m particularly interested in how software design skills can support Lean and Agile software development.

I first explored this technique while working as a consultant in the role of team lead in a large company that was part-way through an Agile transformation. My colleagues and I were brought in to help establish the technical skills and practices that would help the organization achieve further agility.

My team was dedicated to maintaining and developing important systems, and had little time to commit to learning activities. They were experienced coders and were really motivated to learn new things, but they hadn’t engaged recently with questions about what makes good code, and how to go about creating it. My challenge was to find the most effective way to catalyze their learning, whilst using as little of the team’s time as possible.

My values

In drawing up this technique, I drew on four key values:

• A shared vocabulary. We have more powerful conversations when we can name and discuss the patterns, principles, and concepts in play. Building and exploring a shared vocabulary lets us engage mindfully and deliberately with the code we write.
• Repetition. Very few of us fully understand or remember a concept the first time around. We build familiarity through repeated exposure.
• Contextualization. Concepts make more sense when we can relate them to our actual work and to other concepts we’ve encountered, rather than when they’re presented in the abstract.
• Varying perspectives. Each of us engages with ideas differently, and an explanation that resonates with one person will have little value to another. Fortunately, there is a great deal of overlap in many software concepts, and by approaching the same ideas from many angles, we can give everyone the best chance of understanding the fundamentals.

Microlearning

Bearing these ideas in mind, I introduced a five-minute session after our daily stand-up in which I would lead a very short discussion on a single topic. We called this practice ‘microlearning’. (Years later I discovered that this name has already been claimed, and that, gratifyingly, it describes a body of practice that has many similarities to our daily sessions.)

By taking five minutes a day, we were making no appreciable dent in the team’s capacity, and by scheduling this session after stand-up, we could ensure that all team members were present and that the flow of activities was not interrupted.

The form of the discussions

I kept a stack of index cards on which I wrote the names of the concepts we wanted to explore. For each session, I would select a card – sometimes at random, sometimes in response to the team’s current work – and lead a short discussion.

This discussion could take various forms:

• When a concept was new to the team, we would call on someone to introduce it. I might then act as an expert and explain the concept to the team, or I might ask a team member to do some research beforehand and bring their findings to the session. By continually adding new concepts, we were able to build up a shared vocabulary, which we could refer back to during code reviews and planning discussions.
• Often we would revisit a concept we had previously discussed. I would pick the card out of our stack and call on the team members to explain it. These revision sessions gave us an element of repetition.
• In the course of the discussion, we would ask whether we had encountered this concept in our recent work, allowing us to contextualize it.
• We would also ask how this concept relates to other concepts we had discussed, giving us varying perspectives of a fundamental idea.

As an illustration, let’s imagine we’re revisiting the code smell Shotgun Surgery. The discussion might run like this:

Me Can anyone give a quick explanation of Shotgun Surgery?

Asif Is it when you find yourself editing the same code for lots of different reasons?

Me That’s actually a different smell. Can you think which one that might be?

Bethan That’s Divergent Change.

Me That’s it.

Asif So is Shotgun Surgery the opposite? When you have to edit lots of files to make one change?

Me Spot on! And have we had any examples of this recently?

Clifford We introduced a couple of fields to our bookings table, and had to pass two new parameters all the way down from the request handler.

Me Can we think of another smell that describes this situation?

Denise Data Clumps?

Me That’s the one. And are there any related principles?

Clifford Coupling?

Me Mm?

Clifford Because all these method calls depend on the same group of parameters.

Me Yes, nice!

Bethan How about Encapsulation? If we had encapsulated all the parameters in a class then we would only have to add these new fields in one place.

Suitable topics

This technique works really well for subjects that are broken into small elements, for example:

• The principles behind the Agile Manifesto
• The types of Agile Testing, and their location on the Agile Testing Quadrants
• Code smells as described in Martin Fowler’s Refactoring
• Software design principles, such as coupling, cohesion, and connascence; polymorphism, abstraction, and encapsulation.
• This is also a great exercise for discussing words in your domain language, which can support Extreme Programming’s System Metaphor and Domain Driven Design’s Ubiquitous Language.

When to move on

This technique is most powerful when used to build a strong conceptual foundation for further learning. Once learning is a regular part of a team’s routine and its value becomes apparent, it may become possible to make time to learn skills and concepts that can’t be practiced in five minutes a day.

• Coding sessions are a great way to practice test-driven development, refactoring techniques, or simply brush up IDE skills.
• Whiteboard sessions and group discussions can give us time to dig deeper into technical subjects.
• Games and group activities can help us explore communication techniques and learn about software interactions through physical activity.
• We can learn from other practitioners and experts by running book groups and sessions to watch or listen to talks and podcasts.

Why not get started today?

The great thing about this technique is that you can get started with very little commitment. If you’ve been looking for a way to introduce learning into your routine, then ask your team whether they would like to set aside these extra five minutes, agree a shortlist of topics for your first discussions, and give it a go!