Sébastien Ménétrier
Transcript (Translated)
We are going to discuss how, within a team, and why not later within an organization, to implement a skills development policy, a knowledge-sharing policy among people. And we will see how we can do this, not on the fly, not in an emergency when needs arise unexpectedly, but how we can do this in a rational, organized, and obviously prioritized way to make it effective.
So, just before we start, I will introduce myself very briefly. Sébastien Ménétrier, I work for the company SOAT, as you can see written just about everywhere. I am also the secretary of the French Cambron User Group. So, we organize about once a month evening events. Around combat and everything related to it. So, do not hesitate to sign up for our meet-up for the next event on November 20th. There will be one in December about Games, so feel free to join us. Alright, end of the promotional parenthesis. Let's go.
So, the first question we should ask ourselves before starting anything is: why are we going to do these things? Why do we need to implement a knowledge-sharing policy within a team? First, an observation.
The observation is that most of the time, within our teams, people tend to be specialized. Whether it was a decision made when creating our team—we build a team to respond to a project, and we form it with specialists in this or that technology, specialists in this or that functional domain, or even if at the beginning of the project we have a team with people who are at roughly the same level... with roughly equivalent knowledge, through practice, we will very quickly end up with specialized people in our teams. I am a developer, I start working on the accounting module, new requests come in for this module, and very naturally, it will fall on me. And very quickly, I will become the expert on the subject, and not only will I be the expert on the subject, but I will be the expert by default for the other team members. I will be the only one who knows this subject.
So, we have teams with specialized people in them. Alright. But is that a problem? After all, each of our developers is in their comfort zone. We know very well that we cannot have a team with only people who are specialists in everything.
Requests come in, we have people who are very effective at handling them; this could be satisfying. It could be, but it is not as satisfying as that because we can identify at least three problems with this. The first problem—I don’t know if you are familiar with this theory—is what we call the bus factor. So, the factor... of the bus. It’s a bit morbid, but basically, ask yourself in your team: if such a person, coming to work tomorrow morning, gets hit by a bus. I told you, it’s a bit morbid. If such a person gets hit by a bus, can my project survive? If the answer is no, it means you indeed have a very, very big risk. People specialized on a project represent a huge risk. Now, without going as far as getting hit by a bus, simply a sick leave can put you in jeopardy. And then, these factors of... lack of serenity within the team because, quite simply, people cannot take vacations freely. There you go, I am the expert on the accounting module. Okay, I don’t take vacations because if there is a problem, no one can fix it. In the long term, we can immediately see that this is not sustainable. Alright? So, a specialized team poses risks.
A specialized team also causes issues in terms of possibilities. Let me explain.
So, let’s take our expert on an accounting module again. We have an expert on a human resources module in our application. I don’t really know what this app does, but let’s assume. Requests come in, we have a whole backlog of requests to handle, and the priority requests only concern accounting. And we have a lot, a lot, a lot—enough to keep us busy for a month or two. Except that we only have one person who knows how to work on it. We will end up having to feed our HR expert with non-priority tasks just because we don’t have the capacity to handle the priority requests. Alright? So, we will... respond less effectively to our clients' needs. So, this is the second problem we can encounter with having team members who are too specialized.
And then, we have another point that will encourage us to implement these skills development policies: it is a motivating factor, skills development. Let me briefly remind you of the fifth principle found in the Agile Manifesto. Deliver projects with motivated individuals. Why do we want to motivate people? We know very well that motivated people are more effective, that motivated people will be more loyal to our project. When I talk about loyalty, it means we are in contexts—I imagine you know this—where there are a lot of contractors. Contractors can very easily leave a project and go elsewhere. So, by keeping people motivated, we are more effective, more sustainable, and we have a project that can go well over time. And therefore, ensuring that the people working on our project are guaranteed the opportunity to develop their skills and that they will not stagnate only on the same module, the same technology, the same part of the application, will help us; it is a very good motivating factor for our teams. Alright? So, risk reduction, increased team capabilities, motivating factor for our team members. So, three reasons that I personally consider quite important for implementing a skills development policy.
Alright, but implementing a skills development policy takes time, so it costs money. It costs our project. If you tell your client, 'That’s great, but this week I’m sending everyone to training, we won’t deliver anything,' it’s likely to be a problem.
So, we will need to find a way to implement this skills development policy that is painless, or at least as painless as possible for our client and for our team’s performance. Now, skills development is an investment; it will always cost something. We will try to ensure that it costs as little as possible. Alright? Among other things, by prioritizing actions, by developing skills in the most important areas. So, I will propose to you—a plan based on what I have been able to implement in different teams in recent years—a five-step plan, five actions.
First step, we will first take stock of what our team knows, what our team is capable of doing. Second step, we will look at what our team wants to do. Third step, we will no longer focus on the team but on the project. What does my project need?
Fourth step, we will compile all this data to organize the skills development as such. And fifth step, we will maintain this policy over time. And even, as a fifth additional step, we will try to expand it to our organization.
So, first step, we will take stock. What can the people on my team do? So, we will use a tool that you may have already used yourself. It’s a tool called a skills matrix. I will show you an example right after, but basically, what is a skills matrix? It is listing the skills necessary for my project.
Matching these skills with the people and seeing who can do what, at what level. Alright.
Now, there are some pitfalls to avoid when creating this skills matrix. The first step is to list the skills we need. The easiest way to do this is to gather everyone around a table and say, 'Okay, in your project, in your context, what are your skills?' What do we need? When we talk about skills, we will just as well talk about technical skills. We need knowledge in Java, we need knowledge in WebSphere, in whatever you want. And we will just as well be able to talk about functional skills. We need to know about the accounting module, the human resources module. Such and such other module. We can also have things that are a bit on the borderline, which are more about know-how. I know how to do a production deployment. So we will start by listing all of our skills. So here, we can also do a bit of forecasting. We will look at all the skills that are necessary at time T on our project. Then we can perhaps also project ourselves. I think we will have this or that opportunity, that we will have this or that need in the future. So I note the skills that I will need soon.
So, when you do this skills assessment, pay close attention to granularity. I'll give you an example. Saying that I know Java is perhaps too broad. Java represents a huge number of frameworks, modules, libraries, whatever you want. It's perhaps too broad. On the other hand, going into too much detail might go too far. So we will need to pay attention to granularity. So, there is no magic formula. Roughly, what I have seen that was effective in my skills matrices is not to have more than 30 different items. 40, maximum, really for very large teams with very complex applications. If you have more columns than that in your matrix, it might be that you are going a bit too far. There may be some groupings to do. In any case, they risk being more difficult to maintain. Good. So now, we have listed our skills.
We have listed the people on the team, that won't be the hardest part. Now, the idea is to see who knows how to do what. There are several ways to do this. The one I will favor is simply asking people to self-assess. Okay? This is where we will have, on the one hand, the truth. Because as a team manager, I think that so-and-so knows this. Maybe I am wrong, maybe I am misjudging their level. And then very probably, the person in question has knowledge that we have not yet put into practice, so I am unaware of it. So we will ask people to self-assess their skills. Now, for people to be able to self-assess, what is very important is to give them an explicit scale. If I ask you, so in Java, how much do you know between 0 and 5?
It's very complicated to say. However, if I give you an explicit scale, 0, you know nothing at all. 1, you can work on it, but you are not autonomous. 2, you are autonomous. 3, you are able to train on the subject. So if I can give you an explicit scale, then you will be able to self-assess.
So, once we have determined our matrix, we have it filled out by the members of our team. Then, possibly in a second step, we can have it reviewed by a tech lead or someone who knows the project very well because sometimes people have misconceptions about their skills. So we can go over it again to check if everything seems coherent to us. Why not? So that's roughly what a skills matrix can look like.
At the top, I put the scale I used for this project.
So we listed the technical skills at the top, the functional skills at the bottom, and the people self-assessed on all these subjects.
So that is our first step. We take stock of what exists in our team. Regarding skills, once again, that we currently need, and why not, that we might need in the future. Second step, now that I know what my team knows how to do, I will see what my team wants to do.
The key to a successful skills development policy is voluntarism, it's about developing people's skills. on subjects that interest them. So, we take the same matrix, the same list of skills, the same list of people, and we ask people to tell us, okay, what do you want to develop skills in? And what is important to highlight also, is to see what you definitely do not want to develop skills in. There are people who are not at all interested in such a functional area, who are not at all interested in such a technology. Okay, it's important to know that. And then obviously, on other subjects, we might possibly remain neutral. So this will give us, still on the same project,
it can give us this type of wish matrix. So in green, the willingness to develop skills. In red, the 'no, I am definitely not interested, I do not want to do it.' We see that our friend Thibault is not interested in much.
And in white, okay, we remain neutral. Very well. Okay, so there I focused on the people. Now, I will focus on the project. I will take my skills matrix again and looking at it, I will see where my gaps are. Okay? And where I am well covered? So, this can be quite easy. Indeed, in such a column, I only have one person who knows. I potentially have a gap, potentially a risk. In such another column... I have lots of people who know. Okay, I have no risk.
No opportunity to detect. Well, it's not necessarily as binary as that. Sometimes, indeed, such a module, I only have one person who knows it, but I know very well that it is not a critical module and I know that I have a request every two months on the subject. One person, okay, that's sufficient for now. Conversely, such another skill, I have half of my team who knows it, but I know that my project is going that way, so I need to develop other people's skills. So determining where I will develop skills is not mathematical; it obviously requires knowledge of the project, knowledge of the context, and being able to project a little into the future. I have loads of people who know, okay, I'm not at risk.
No opportunities to detect. Well, it's not necessarily as binary as that. Sometimes, indeed, for a given module, I only have one person who knows it, but I know very well that it's not a critical module and I know that I only have a request every two months on the subject. Only one person, okay, that's enough for now. Conversely, for another skill, I have half of my team who knows it, but I know my project is going in that direction, so I need to have other people build up that skill. So it's not mathematical to determine where I will focus my skill-building efforts; it obviously requires knowledge of the project, knowledge of the context, and being able to project a little into the future.
So I will be able to determine. Generally, what I put in place is that I will determine my next three priority skill-building areas.
And then, it's very simple. I look at where I will build skills. I look at my second matrix. I see who wants to build skills on the subject. That's perfect. All I have to do is put a name next to each skill-building area.
But be careful about the frustrations this might generate. First of all, when you set up this type of system, you must already be very clear with the people on your team. Not everyone will be able to build skills in all their desired areas. It's just not feasible; we don't necessarily have the budget for it. So, there you go, we won't be able to do everything. And then, a second possible frustration,
Be careful not to always have the same people building skills. Try to distribute skill-building over time among different team members. After that, obviously, if you have someone like Thibault who doesn't want to build skills in anything at all,
there's not much you can do; we'll exclude him from skill-building, too bad. But be careful to manage the possible frustrations this might trigger within your team. So here, we see the part that was at the bottom of the skills matrix. This is where I always indicate the priority of the skills I want to build. I simply put 3+, 2+, 1+, and each time a skill is built, I add a new skill to the scope of my skill-building efforts.
Good.
So, we know what we need to build skills in, we've prioritized, we've assigned people. Perfect. Now, how are we going to concretely organize this skill-building? Well, there are loads of ways to do it. I won't go into too much detail; we'll go over a few methods. In fact, I would be very interested in the Q&A session that follows if you have any remarks, recipes, or things that work very well in your teams, It could be interesting to discuss them together.
So how do we organize this skill-building? First, we can look outside the team.
We can simply do training. We can bring in an expert. Whether it's an expert internal to our company, we'll ask for help from an architect, or bring in an external consultant.
That's very good, but it can be potentially costly, especially if we involve people outside the team. Sending an entire team to a two-day training session, That has a cost in our budget.
So it can be effective, but it's costly, so it should be handled with care. There's another element that is often neglected, but which is not costly at all, It's, I don't know if you're familiar with Lucoman's Innovation Games, which are a set of facilitation and meeting techniques that allow us to create innovation. Among others, there's an exercise I really like, described in this book, called Me and My Shadow. And basically, Me and My Shadow is about going to see how others work. Okay? I sit next to them and watch. To learn the functional aspects, to learn the business behind the product we're working on, if we have access to our end users, let's simply go see them work. I come for two hours, I sit next to you, I watch how you use my product. And I don't disturb you. If there are points I don't understand, I might ask you to explain. But I intervene as little as possible. I observe my product, what it's used for. The contact module, what exactly does it do? How? You use it. Okay? And there, I can build skills quite easily and at a low cost.
I can build skills in the entire business area. Okay? So, to organize our skill-building, we can indeed look outside our team. Now,
To build skills, we can also simply look within our team and share knowledge within our team. So, I've given you the scale that I usually use. So, zero, no knowledge on the subject. One, partial knowledge but not autonomous. Two, autonomous on the subject, 3. Experienced, able to train people on the subject, 4. Expert, I am the reference on my subject within the team, or even outside the team.
So everything depends on what level of gain we want to achieve. So what we can do, for example, if I want to go from level 0 to level 1, we can settle for theoretical training, a commented presentation of the code, the architecture, a demonstration of the use of a business module. To go from level 0 to level 1, training, demonstration, presentation.
And the 'me and my shadow' that I place a bit at the border between internal and external, it depends on the context.
Going from level 1 to level 2, that is, becoming autonomous on the subject, requires practice. But to practice when you don't know much, the easiest way is to practice with someone. So, an excellent way to do this is pair programming. For example. Okay? Now, I think many of you are familiar with the concept of pair programming. For those who don't know, it's very simple. We will be two at one keyboard, okay? Working on a single subject. And we pass the keyboard from one to the other regularly. Okay?
And so the person who is coding can explain what they are doing, the person next to them can ask questions about why you are doing things that way. What are you thinking right now? Why are you doing this thing? So pair programming, that works rather well.
I'll allow myself a very small digression, by the way. So, we're talking here. My case study is when I join an already established team and try to distribute knowledge about what already exists. Pair programming is an extremely powerful tool that you can also use. Before you need to share knowledge, you have a new module coming up, you have very complicated things to do on it, start with pair programming right away. It will always be less costly to share knowledge from the start than to do it a little later. I strongly advise you, on the tricky points you might encounter in your projects, to start with pair programming right away.
End of the parenthesis. Other ways to move from level 1 to level 2 in skills include doing dojos. Okay? So, dojos are simply one person... Explains things, several people are listening, one computer, one keyboard, we pass the keyboard around, we program together, and we learn things together. Okay?
In a dojo, we often—though not necessarily—work on theoretical subjects, not necessarily on real elements of our application. We will learn things.
Something that is at the boundary between dojo and pair programming is what we call mob programming. We all work together on a single feature. Okay? So, that works quite well too. I’m going to take the liberty of promoting a friend on the SWAT blog. If you don’t know about mob programming, there’s a very didactic article on the subject that I strongly encourage you to read. It’s quite interesting.
Moving from level 2 to level 3, so we’re already autonomous, but we really want to improve our skills on the subject.
We don’t need as precise a framework as pair programming, but we can, for example, do what’s called mentoring. Mentoring is when I take a subject I’m not yet very comfortable with, and someone who knows it will explain to me a bit generally the pitfalls to avoid, the architecture in which to evolve, the points of attention, all that, you see. Okay, I’ll work autonomously on the subject, and then, code review with the person next to me, and we’ll see, we’ll comment, etc. And we learn.
In general, doing code reviews also allows us to improve our skills.
Finally, becoming an expert. To become an expert, you have to practice. And possibly, here, we can also step outside the team and look at communities of practice outside our team, more broadly within our organization.
So, here are a number of possibilities we can implement to share knowledge and improve skills. Obviously, these are not the only ones. I’ve only given you a few examples that I apply quite regularly in my projects.
So, all of this is very good.
But concretely, what’s the pace for doing this? We must not forget that we have a client waiting for us. We need to deliver things; we need to produce value. Okay? So, what’s the pace? So, the first point, we’ve already talked about it. We will prioritize. Do we already have emergencies? Do we have major risks that absolutely need to be mitigated? Do we have opportunities coming up very quickly that we really need to be able to take into account? So, we will prioritize things. Once we’ve prioritized, we will... What I implement—for once, there are other ways to do it—but what I like to implement are sessions. To improve skills. So, depending on the size of the teams, I will schedule one or two sessions per week to improve skills. Sessions of between two hours and half a day, which is roughly the same depending on your teams' rhythm, you’ll see. So, we will set up skill improvement sessions. And these skill improvement sessions, I track them to make sure I don’t forget, to ensure that in a panic, 'Oh yes, we were supposed to work on this subject but I didn’t have time.' I track them. So, here I will use visual management. I can use sticky notes of a particular color, I can put a... Put a magnet of a particular color to say, 'Here, attention, on this subject, we are going to share knowledge.' Well, we find ways to do it, but we track it and don’t forget it.
Eventually, when we find the right pace, when we implement these kinds of things, we may face external pressures telling us, 'Yes, that’s nice, but while you’re doing that, you’re not delivering value, or at least you’re not delivering it as fast as expected.' So, on this, a good support can be to rely on human resources. What we’re doing is improving people’s skills. Again, we’re contributing to people’s motivation. So, it can be extremely interesting to rely on human resources. And a final point of attention on the subject: we have people who are learning, and then we have people who will teach others. So, here too, a small point of attention. Don’t focus, don’t always rely necessarily on the same people. Okay? Again, there’s no absolute rule. There are people who will love sharing their knowledge. There are people who won’t like it much. So, be careful. In a pairing company, the expert must be willing and motivated to do it. Otherwise, it won’t go very well. So, be careful too.
At this point.
Good.
So now it’s good, we know who, we know what, we know the rhythm. So now, let’s go, it’s time to start. So, I told you, one of the good ways for this to work over time is to track it and display it. We use the power of visual management to ensure it’s actually done. Now, be careful with this visual management—I’ve encountered this very rarely, but I have encountered it. There are people who don’t like it to be displayed that they are learning things because it implies they don’t know. So, sometimes you have to be careful with some sensitivities. It’s still quite rare, though.
For this to work over time, your matrices must also be up to date. Ah yes, we have people improving their skills. So, the skills matrix necessarily evolves. And then we may have new columns appearing, new skills we will need. So, we need to maintain our matrices. And then we won’t maintain them—it’s not me, the team leader, who will maintain them. I know there has been such skill improvement, okay, I’ll increase. My skill? No, obviously I have everyone fill it out because there are skill improvements I may not necessarily be aware of. People also improve their skills on their own. So, maintain and challenge the list of skills so that it can last over time.
And so, once we’ve been able to put all this in place, we are now in a virtuous circle where our teams can improve. So, we are clearly in pure continuous improvement. And we can go a step further and why not share. We have people who have improved their skills, we have people who know how to do things. Well, let’s share that with other teams. And how? For example, let’s run dojos in other teams. And there, it will be a quid pro quo. I come to facilitate a dojo on a certain topic in your team, you come to facilitate a dojo on a certain topic in my team, and that way we can spread knowledge. Distribute it throughout our entire organization. And so, we reduce our risks accordingly and bring serenity to our teams. Very practically, people can take time off when they want without putting the project at risk. It may not seem like much, but it's important.
We increase our teams' capabilities, we increase the opportunities we offer to our clients, and we have people who are much more motivated, so they work better. That's what I had to say on the subject. I hope this interested you. And if you have any questions about all this, if you'd like to share with us what you're implementing, or possibly the obstacles you've encountered in your implementations,