#1
❓ Why do we even talk about suboptimal SW engineering approaches?
❓ Why don’t we use the best SW engineering approach for our teams?
❗️ Turns out that context matters here a lot.
The “State of DevOps Report” repeatedly showed, year after year, that stability and throughput are the most important metrics for having high-performant teams. They typically achieve this using test automation, trunk-based development, deployment automation, and several more practices.
Basically, practicing continuous delivery rigorously should help a team become “high performant.”
At least that had been the case until the latest “State of DevOps Report” came out.
This year’s report had a significant change in demographics compared to surveys so far. The share of more experienced respondents (16+ years) dropped from 40% to just 13% which affected the results in such a way that trunk-based development now has a negative impact on the performance of teams. A clear indication that experience and knowledge matter.
❗️ More experienced individuals (16+ years) experience the following effects:
🔼 INCREASED overall software delivery performance
🔽 DECREASED amounts of unplanned work
🔽 DECREASED error-proneness
🔽 DECREASED change failure rate
❗️As a clear opposite, less experienced developers experience the following:
🔽 DECREASED overall software delivery performance
🔼 INCREASED amounts of unplanned work
🔼 INCREASED error-proneness
🔼 INCREASED change failure rate
The results came as a surprise to some but are not unexpected.
💡 Not investing in structured people development backfires!
💡 Now we have measures showing how expensive it is not to invest in building SW dev teams’ competence.
#2
❓ I pay my software engineers well and expect them to be efficient as soon as they join the team!
💡 Not everybody knows how to act as a part of a team or even be a part of one.
💬 Teamwork is an individual skill.
💬 Each team is different.
💬 Every product has its specifics.
💬 People comprising those teams and making those products are not the same.
It is an illusion that hiring someone and assigning him to a team will immediately make him a team member. Let alone an effective one.
There is plenty to be learned. There are at least slight if not essential variations in perspectives regarding all aspects – both organizational and technical.
❓ How many times have you had a new team member being asked to write unit tests without any established baselines to at least understand the basics of the unit testing approach team adopted?
It is somehow expected that “everyone should be able to write unit tests,” which is a reasonable expectation. Too bad there is no standard for that. How about the approach? Agreements and explicit policies?
❓ How many times has somebody on your team asked for or has been instructed to “do the refactoring” which lasted for days, weeks, or months, leaving the code unintegrated for all that time?
Refactoring is, in fact, well described and understood practice. However, it is most often mistaken for something it isn’t. Most likely it is a redesign effort disguised as “refactoring.”
There is also a misunderstanding of the essence of the practice that it is a series of micro modifications, each leaving code in a working state – the same as before but slightly better structured.
Do you educate your team members about that constantly?
❓ How about code reviews? You are a senior developer – do a code review!
How to do that? I am sure that everybody has his preferred approach. Is it preferred for the team? Is it agreed with the team? Is it expected by the team?
Expecting one to be effective and efficient simply because they got the job is often unwarranted and simply unrealistic.
💡 Regardless of how senior the new team member is, a mentorship is due – every new team member is new to the team, the process, and the technical approach team uses. He is quite possibly new to the product as well. Thus the need for them to learn about that stuff.
#3
❓ How should I add a new member to the SW development team effectively?
❓ If simply adding a new developer to the team is not enough, what should I do then?
💡 There is a highly effective approach you can use to introduce a new team member to the team ⤵️
The goal of adding a new team member to the SW development team is to get a highly-effective, completely integrated, and competent team member.
💡 The following 4-step approach provides exactly that!
1️⃣ Directing
Upon being added to the team, a new member has to be introduced to the work agreements and code of conduct (written or otherwise).
Those are usually a part of onboarding procedures and provided documents to newcomers.
💡 For a software development team, those should include all the rules and work agreements formulated by the team thus far (e.g., details about the approach to design, code specifics, unit tests, automation specifics, source control, configuration management, just to name a few)
This step is intended to provide an encyclopedic overview of all the relevant information, collected by the team over time.
2️⃣ Mentoring
Regardless of the seniority of the new team member, every new team member needs mentorship.
Even if the newcomer is the best expert in exactly what the team needs, he needs to adopt specific team rules and work agreements effectively.
💡 We are effectively adding a stranger who just walked through the door to the team – so we should do it with care both sides deserve and need.
Moreover, the practices, habits, or preferences of the newcomer might not suit or fit the team, so this is the phase where to iron out such discrepancies.
This is especially important for universally misunderstood terms: CI/CD, test automation, TDD, trunk-based development, pairing, mobbing, refactoring, code reviews, and such.
3️⃣ Coaching
After successfully exposing the newcomer to the rules and work agreements, as well as helping him effectively adopt them via mentorship, the newcomer is one step away from being an autonomous part of the team.
This phase benefits from the previous steps by coaching the newcomer to autonomy.
4️⃣ Autonomy
This is the end phase where we get a fully integrated and performant team member.
❗️ Companies generally resist such an approach. It is universally expected that just selecting a candidate, and adding him to the team is enough for the team to absorb that addition. Such missteps and wrong assumptions come with a cost, which mostly exceeds the investment needed to properly introduce a newcomer to the team (often by orders of magnitude).
#4
❓What is the cost of not educating new team members?
📄 The famous quote says: “What happens if we invested in our people and they left? Yes, but what happens if we don’t invest in our people and they stay?”
The corniness of the quote aside, the point it makes is critical to grasp.
As discussed above, every team member should undergo team induction steps, even mentorship, and regardless of seniority.
Such activities count as a form of education too. Educating new team members that way takes time and costs money. Thus it will add to the cost and will slow the team down.
Now, let’s consider the opposite – deciding not to invest in education.
Unless the new team member has been on exactly the same team as the one he is joining, there will be at least some differences. Regardless of their seniority.
Failing to understand those add to cost at every step:
📄 Misunderstandings due to differences in:
➡️ Expectations about the level of detail discussed
➡️ Approach to business and technical analysis
➡️ Understanding of various technical practices (due to semantic diffusion, i.e., the difference in meaning for the same things) – e.g. what is a unit test, what is TDD, what to automate, how to split the story, what is a user story, etc.
➡️ Understanding what teamwork and working together are
etc.
📄 Rework as a direct consequence of misunderstandings listed:
➡️ The back-and-forth between the ones writing the code and those testing it
➡️ The back-and-forth between the ones writing the code and those reviewing it
➡️ The back-and-forth between the ones implementing the solution and those accepting it
➡️ The back-and-forth between people formulating requests and those implementing them
etc
📄 Lowered quality due to:
➡️ Anti-patterns stemming from listed above and stemming from all the above
➡️ Unrealistic expectations coming from inefficiencies resulting from all the above, which leads to time-pressure
➡️ Trying to address or prevent delays produced by all the above
📄 Demotivation as a result of all the above leads at least to:
➡️ A vicious circle of further low-quality results and demotivation
➡️ Individuals and groups leaving the company, taking siloed knowledge with them
💡 Educating new team members properly slows down a team shortly.
💡 Not educating new team members is the death of thousand cuts – slow and painful. It slows the team to a grinding halt.
In both cases salaries are due.
❓ Which one is more expensive?