I was hired in December last year to lead and mentor a team of 4 devs and a tester. It was my first time as a team leader, even though I've already taken the role of mentoring some people before when I worked closely with some colleagues. I want to write down what went right and what could have been better and what lessons have I learned from this experience.

Context:

A rewrite of one of main server applications of the company to be more flexible, faster and more reliable. The team would be doing it the XP way. Only I, in the team was familiar with XP practices.

the team:

The team of constituted of two senior devs, one with 10+ and other 5+ years of experience, a junior dev with almost 2 years of experience, me and a young and inexperienced tester.

The team was never steady and the tester was almost always busy testing other applications, or bug fixes from the previous versions.

The senior devs, that built the previous version, were being pulled away from the project to fix problems/bugs related to it.

The junior dev was still in another project and only joined the team 4 months after it started.

I was able to pair programme for most of the first 6 months with one dev at a time, while others were busy doing things unrelated to the project.

the way I mentor:As an XP advocate, I used pair programming as a way to pass on knowledge of the practices. I believe that being assertive and making people think is more effective as they will find the answers by themselves, so they will retain the finding more easily.Some people might think that this way will came out patronising and arrogant.

I think that if people are truly interested in learning, they will be thankful and happy that I didn't gave them the recipe and that I went out of my way to explain to them how things work when they admit they were lost. But I was wrong.

Most people think differently from me and even though they are interested in learning, the method I used, and that it was effective to other people before, was not suitable for them. I failed to realise that this way of mentoring was the root cause of the problems that arose.the progression:

While the progression with one of the senior devs was steady and fast, as he asked for help when he was lost and tried to take in my advice, the other senior dev resisted and never asked for help, so progress was fairly slow.

I have to say that I'm a very patient person and I let people take their time to think about the problem and the solutions. If I find that people are not communicating, I ask questions like: What's the problem we have to solve? What do we want to accomplish here? How can we fix this now? or Can you see a better way of doing this? Depending on the way you take this questions in, you get different outputs.

If I'm not afraid to be wrong, and I think for a bit, take a stab at it and say something, worse case scenario, I was wrong and learn something.

So, I always tried to guide them to the solution by asking more questions or saying things like: What if such and such happens?

But If I'm afraid to be wrong... I might spend a lot of time thinking or just wishing I was not being put in a position where I have to provide answers.

The silence or the questions that come next make the situation worse as I've already closed my mind to find a solution and I'm just wishing for this situation to end. I might just say something just to get out of this uncomfortable position.

And then I say something without really thinking about it, and chances are, I will say something wrong or just plain illogical. So When this happens I tried to show them that maybe they needed to read this on the web or buy a book about the subject. This might come out wrong again depending how I say this things. I tried to be sensible and I think that they took it the right way but I'm not too sure. Though in the end this way was preventing work to be done and slowing the all thing down.

With more or less bumps in the way, we were able to build some software using new tools for them like a mocking framework. And they started testing their software with three kinds of tests (have a look at how I test software), a CI server that continuously integrated our code and run our tests and pairing all the time to spread knowledge. This apart from the other practices like iterative development...

the XP values and corporate values bump into each other:

I mostly struggled to pass on some values that were against the corporate culture. Things like high code quality with simple things like naming, or just plain consistent formatting of the code were a struggle all the way. I tried to infuse this attention to details by showing them that code that it consistent takes less time to read and is much more pleasant. And that good naming is as important as any other thing.

Test driven development was way beyond their capacity as they has their debugging practice too much ingrained in their way of working. I used every example I could to show them what they were missing if they write the tests last but to no avail.

I now think that the push model of programming might be a mental leap that some people find very hard to get their heads around. And that is why TDD hasn't taken off yet, and also because it's hard to do well. It took me 3 years to kind of master it and I know I still have a lot to improve.

Overall:

What I think I failed mostly with was not being able to make retrospectives part of the development process where this and other problems should have surfaced much earlier and should have saved a lot of time.

I've also took some decisions unilaterally which kind of killed the team spirit. Even if I were sure that their contributions were not that big, I should have discussed the problems within the team and facilitate the team to get to an agreement instead of almost imposing decisions on others.