Company Culture Shapes Individuals: Learning Environment

Establishing a learning environment

Let’s look at the different possibilities for establishing a learning environment. Most of these can be learned from experience, and a review team can ensure that these experiences will be shared. It is also worth analyzing how much can be learned from failure and how a culture of failure can foster learning. All these factors impact individual learning during development.

Review team

In addition to a (virtual) technical service team, we might also consider installing a virtual review team to look after the code and design. All the developers are qualified to belong to this team, which means we do not have to specifically pick skilled ones. The review team provides a great learning opportunity for all. The developers will learn a lot by reviewing and seeing different kinds of code, and those being reviewed will also learn a lot from the reviewers’ comments. An internal review team helps to not only improve the code and design but also the skills of everybody involved.

Often, we will see that it is a huge motivation for the developers to belong to the review team. To give everybody the chance to learn through review, the staff of the review team should change over time. Often, the same people will stay together in a team for only one iteration or release cycle. The review team has to be careful not to be too picky because this will hinder the teams from accepting suggestions.

Post-review skill dissemination

To spread the acquired skills, the review team should define the good and bad habits they detect the most often. The whole team can then work on those issues in different ways:

• Somebody can deliver a lecture about the topic in question. If time and money permit, we might even consider inviting an expert in the field to talk about the topic.
• Install study groups focusing on the topic, like pattern-reading groups. Invite all participants to come prepared to the session—this will support learning how to learn—and to talk about what they have learned and what they still do not understand.
• Publish a newsletter, which covers the “dos” and “don’ts” discovered by the review team. The reviewers should serve as the editors. Make the organizational structure of the newsletter as simple as possible: distribute it via email or the wiki web. Make sure it isn’t too long—half a page is fine—otherwise nobody will read it. Make sure the articles give examples and counterexamples to illustrate the points.
• Define one to three topics as focal points for the next development cycle. This means all the developers will concentrate specifically on eliminating bad habits.

External reviewers

Of course, we can also consider occasionally asking external reviewers to inspect the efforts of the team. Sometimes the outside perspective of external reviewers can give us a new insight into our system. However, if the internal review team understands the job, external reviewers rarely add extra value.