Advice on starting to mentor coworkers

Question

I work in a great company (.net consultancy) with some great devs, but some of the older hands have approached me wanting me to help them become "more modern" in their approach to software development. they would like to get more into

• Agile mindset
• TDD/BDD
• IOC/DI

I'm absolutely no guru, but I do have strong opinions on these matters, so I guess that's why I was approached (that and the fact that I'm a helluva nice guy :) )

What I'm wondering is how I should structure this so that they get the most value out of it. I guess me pointing at diagrams and demonstrating code won't be the best option.

edit: to clarify I will probably not have the capacity to meet with them more than on a biweekly schedule for a couple of hours, so the structure will have to have some degree of "homework" element to it, I agree that in an ideal world, I would be able to work with them in pair programming on a relevant project, but they are stationed elsewhere and this will have to happen after opening hours.

Answer 1

Before starting you should have a session explaining the new methodology (i.e. SCRUM, TDD etc.) afterwards try to get everybody on board by suggesting that you try the new methodology for a defined period (one week, one month or whatever).
During that period you need to make yourself available for "mentoring" because your co-workers will need to ask you a lot of questions.

I know it's not always possible but being in the same room (or at least floor) would help greatly because you'll be able to see how well the new methodology is assimilated.

You can use code reviews as a teaching tool (if possible), review your peers code before committed back to the source control. This would work especially with TDD/BDD because you get to review review their test code as well as the production code.

Finally a teaching session is always an option if the 1on1 approach is not possible.

Answer 2

The best way, if possible, is one-on-one pair programming.

Just sit with a developer, and work through specific tasks together. Make sure that it's the mentoree doing the typing, so you're guaranteed to know if he or she understands what you're getting at.

I find this technique works for any kind of programming mentoring. Granted, it takes a lot of your time, but it's great for rapport building, and it reinforces the "helluva nice guy" part.

Answer 3

I think the previous posts have covered most areas of mentoring. That being, a little teaching and little bit of review and a lot of being available to field questions. The only thing that I think I could add is to try and put an emphasis on WHY they would want to use Unit Testing, IoC etc. I think a lot of problems with mentoring / teaching on any subject is forgetting to provide a solid background for why it should be used rather than just mandating 'You should do it this way'.

Just my 2 cents though.

Answer 4

There are at least a few different ways to approach this, to my mind:

Individual vs. group - Would everyone that wanted help all gather for breakfast or lunch to discuss various ideas and theories?

Start small - Don't try to put everything out there. Give bite-size chunks of information and be prepared for follow-up questions about how it went, what was good, what wasn't so good, and all that kind of feedback. I'd probably suggest having a line a week to try to grasp like, "release early, release often," or "fail fast," or principals like KISS and DRY that are various phrases associated with Agile.

Be prepared for some of this to take time and possibly many attempts with different approaches as part of this is changing someone's mindset, philosophy and style that don't change overnight well. You may want to confirm some things like terminology as Agile to one person may not be Agile to someone else.