Published in: Uncategorised

Learning culture in software engineering teams: Make it sustainable (7/7)

This post is part of a series of 7 blog posts on the topic How to create a learning culture for software development teams:

Identify needs and prioritize objectives

Learning is an extensive topic, and one question you will inevitably be asked is: “What do our development teams need to learn about?” You and your teams have the keys to identifying the most relevant needs and ordering the desires according to your current priorities.

You may have already highlighted existing issues: the number of bugs reported to production is too high, new features are delivered very late, asynchronous code reviews are time-consuming and wear out our Tech Leads, and our teams do not talk enough to each other, …

Discussing with your teams will help you to identify each person’s needs and expectations and refine your objectives. Maybe developers want to learn React because a migration project from AngularJS to React is planned for a few months? Or do you want to learn about best cybersecurity practices to avoid risks in your applications? Or Domain-Driven Design?

As with any change management process, it is essential to make all the involved teams. Imposing decisions without consultation is a risk. Your culture of continuous improvement will have all the more chance of succeeding if the stakeholders approve the process and its content. You will also have to adapt to the level of technical maturity of the teams, set expectations on the increase in skills, and therefore go step by step for constant progress.

Get the support of your management

That’s a significant achievement if your Tech teams can continuously progress and acquire knowledge. However, this mindset must go beyond the teams and be part of a corporate strategy and its values.

It is a bad indicator when an organization does not offer sponsorship to help teams progress. Support can take different forms: adjusting the teams’ schedule, providing logistical resources (meeting rooms, even free lunches) during technical workshops,… This is then naturally part of the company’s brand image when this strategy is introduced to your customers and partners: this constitutes a significant point for attractiveness and differentiating yourself in a highly competitive sector.

As we said before, the learning culture is virtuous and positively impacts the performance of companies in their ability to deliver value. It is essential to keep in mind this point of view expressed by Tom DeMarco and Timothy Lister:

“Quality is free, but only to those who are willing to pay heavily for it”

If learning to produce sustainable software requires an investment, the gains in your software design will allow you to deliver more often and with fewer defects. And teams will feel more pleasure and satisfaction in their daily work.

Have you ever heard people say “It costs a lot to reach quality, to write tests, to train people, … “? Probably yes, because it’s still familiar in the industry. Sandro Mancuso, the author of a reference book on software craftsmanship, rightly says:

“Quality is not expensive. The lack of skills is what makes well-crafted software expensive.

This investment can be seen through the prism of insurance for the future of the project and the company. Low-quality software is expensive in maintenance time, customer dissatisfaction, and turnover (flee from this code that I cannot see!). If the benefits of this project of growing our technical skills are sometimes tangible after several weeks or months, the impact of non-quality is generally already concrete and perceptible at the moment.

Learn together with kindness and humility

Software Craftsmanship advocates this posture of permanent learning, the search for reaching technical excellence, sharing, transmission, companionship, and mentoring. Therefore, the principles of “know-how” are required so that teams feel comfortable in this process of technical progression.

In the book The Psychology of Computer Programming (1971), Jerry Weinberg sets out the ten commandments for ego-less programming, which detail what attitude to adopt towards the other members of my development team and best practices during discussions and technical exchanges around the code. The notion of ego is particularly discussed, as it can cause havoc in the presence of people with a strong ego and a lack of open-mindedness. Therefore, these commandments promote humility, benevolence, respect, open-mindedness, acceptance of choices for common wellness, questioning, and generally sharing with others. This may sound like an obvious statement or common sense, but it is essential to learn as a team to keep the will and desire to do so.

Have you heard of Google’s Project Aristotle? This study, which started in 2012, tried to answer the following question: “What makes a team effective at Google?”. Intuitively, some people might think that the main factors are the years of experience on the team members’ resumes. However, the #1 factor that came up was psychological safety: each person feels comfortable taking initiative without fear of failure and being vulnerable to others. In practice, this results in situations where I am comfortable to:

Solicit a code review and don’t have any apprehension about collecting feedback;
Suggest best practices during Craft Workshops, even if I’m not 100% sure of myself;
Speak openly about a problem I am experiencing or a situation that puts me in an uncomfortable position.

We often forget to say it, but being a software developer combines technical skills and soft skills.

Iterate and collect feedback

Have you set up specific actions to initiate this technical progress process within your teams? Whether at the beginning of the process or several months later, one action remains essential: collecting feedback from your teams.

What are their feelings about the coaching if an external technical coach is called in? Is the content proposed in the e-learning platform relevant and of good quality? Do the code review processes provide added value? Does the internal BBL’s organization allow the maximum number of people to come? All these questions deserve answers and will give valuable insights.

Whatever formats and practices you put in place in your teams, they must bring value to the people involved. This is crucial to sustaining this knowledge culture. If you are in a context of psychological safety, it will go even better because everyone will feel comfortable expressing their point of view. The goal is to understand how to refine or optimize the proposed formats to perceive further the value delivered, identify possible problems, and provide answers.

Therefore, it is important not to impose formats at all costs without seeking to know what the people who take part in them think. This is not the time to demoralize the teams or alienate them; it is sometimes challenging to recover from a failure or a first bad impression.

In a transparent approach, it can be interesting to share publicly the teams’ feedback to bring a more global dialogue within the company and to produce assessments at regular intervals. This is a project in its own right and should be part of the teams’ daily routine.

Extracting trends and identifying added value

A key aspect in any investment to demonstrate any added value or gains from this strategy of technical progress of the teams? Let’s be honest: we don’t have any miracle formulas, but we suggest ways to identify trends in the added value of the approach.

A significant axis concerns how the teams feel about this. As we said before, buy-in is essential to the success of a project. It isn’t easy to demonstrate a tangible gain if the teams do not feel like learning concepts and making progress. We have to trust our teams’ ability to affirm that the approach is favorable for them. In the longer term, your organization’s turnover rate and attractiveness are also good indicators. It is not uncommon for a developer to leave the company because they feel “stagnating” technically.

It is also possible to formulate expectations and assumptions. A concrete case is the ROE (Return on Expectation) used in a learning and training context. It consists of formulating our objectives before a training course and evaluating whether, in our opinion, the training had an impact on us to meet these objectives sometime later. We can also go further by using the Hypothesis-Driven Development Story Template technique from the Lean community, which suggests indicating in the form: “We think that such and such an action: … will have such and such an impact: … we will know that we have succeeded if we observe… and for this experience we will do …. The logic is the same: what is expected as output, and how can we measure it?

We can also look at Accelerate and the 4-keys metrics presented at the beginning of this white paper. After all, if we have progressed technically, some metrics should evolve in the right direction. Perhaps we will see fewer bugs, fewer rollbacks in production, or a shorter time to deliver features in production. Other indicators can be used from quality measurement or even from our project management tools. For example, a low rate of “unplanned work” (bugs to be fixed, refactoring work needed to move forward on a task, or in any case an unplanned task) at each iteration will indicate a positive trend in the quality of your codebase.

The final word

Through this blog post series, we emphasized the importance of helping your teams create a knowledge culture to progress technically and regularly deliver added value to your customers. Producing maintainable and scalable software is not innate, and it is a range of know-how transmitted through teamwork. Therefore, this learning culture is essential to remain competitive in your market and stay attractive. We have presented different approaches that promote this culture within your organization.

Perhaps you apply some of them daily, and maybe you have discovered new ideas to test in your context. These solutions are not exhaustive, and there are other approaches that you can imagine. In any case, the company must support everything that will be implemented, and the teams’ feedback must be collected continuously to refine the formats.

If you have any questions, would like to share your current issues, or present us with formats that have worked in your context, contact us, and we’ll be happy to discuss them together.