How to make better software developers out of less-than-average ones?

Question

I've asked this before in other places, and I'm now turning to you guys to see what sort of advice you can offer.

Some background: I'm a project manager at an offshore company. I’m in no way the best that’s out there. Most important (or so I believe) is that I am just as good as my team is. I've been at it for the last 3 years. I don't get to choose the people I work with (can't hire or fire people). We are using all sorts of methodologies (agile, scrum, waterfall, RUP, you-name-it). We are holding both weekly and milestone meetings in which we are trying to learn what went wrong/right. So,this is not a question of motivation (my employer is paying them more than fair, they get full employment benefits, etc ), nor one of simply teaching them new skills. This is more about addressing a problem within the mind-set of the average developer.

I've worked with a lot of people both good and bad during the years. There were a few of them exceptional, but most of them were less-than average. Most of the times I'm usually confronted with guys that are getting stuck way to often, guys that are skipping solutions as they are not careful enough to see past their own coding mistakes and guys that are simply drifting away from the tasks to wherever their day-dream takes them. I was wondering if (and how) can they be determined to properly pay attention to their work, to be able to determine solutions and to unstuck themselves without me having to check on their work 24/7. I would really love to worry myself that I'm intervening in their work too much, that I'm always giving them the solution without letting them think. But at this point, I can't see this happening

Some ways I've been suggested to try so far are:

1. Make them read “Addison Wesley – Pragmatic Programmer” and "Clean Code: A Handbook of Agile Software Craftsmanship" – hold periodic meetings for each chapter and discuss what they have learned so far.

2. Hold some sort of "Quick&Great Code of the Week competition", using a new/unknown language for implementation – given that this would be a new language for everyone, this should give me/us an idea over who is missing what.

3. Get the rest of the management team to analyze "a great TED talk about motivation by Dan Pink" and see if we find anything that works for further motivating them.

So, I'm now wondering: is there anything else? would this approach work?

I'm also worried that even though I'll eventually set them on the right track, once the current project closes and the development team gets reassigned, they'll revert back to their old habits. How can I make the knowledge "stick" and prevent this from happening?

Answer 1

From what you are saying the issue is with attention to detail, review, and scope creep? Whilst the points you mention above are useful and provide insight they won't give your team the kind of skills they need to master the development points you are raising. That comes over time with the right direction (I'm assuming the resources you're working with are relatively junior, here).

I'd also say that, whilst it's great to have a knowledge of the various methodologies you mention, it could be confusing to the developer as to what mode they should be operating in. For example, the behaviours I'd expect from a programmer in a scrum environment would be very different from those expected in a more rigid ITIL based methodology. Be careful not to confuse or give mixed messages.

Can I suggest a few things that have worked for me in the past? The key to all of them is to make them regular and reliable. Repetition emphasises importance, and it will also ensure that the knowledge sticks.

1. Work at hand / scope review: A once weekly session to review the work for the week, where it is assigned and, importantly, relate that back to the agreed scope. This gives developers the 'big picture' view that they need in addition to the direction that limits their scope. It also shows how what they do interacts with the work of those around them. Minute that session so that people can refer back to it. The disadvantage with this is that people tend not to shout up if the work defined in that session is completed early ;)
2. Peer review: People will learn greater attention to detail if they are encouraged to perform regular peer reviews of work. We generally create checklists for particular deliverables to kick start this for resources who are already not quite hitting the required standard (eg. Common mistakes to look for in every technical specification). This should also start helping you with reducing your involvement over time as they improve.
3. 360 feedback: Feedback to anyone should be instant in order to have the greatest effect, and should be delivered in a constructive way. Easier said than done, and requires some effort on your part to be willing to be direct. Your developers, depending on the culture in which you are based, may feel less comfortable giving feedback to you, though. Part of making this work is allowing them to let you know what their issues are. You'd be surprised how often there's another reason for poor attention to detail and you should seek to tease this out of them in order to ensure your team is more effective.

Answer 2

The first question I have back at you is, what benchmark are you using to establish "average." You say, 'most are below average.' I would bet the performance of your most is your average. I would further bet that your population of workers fits nicely into the standard performance curve, which means your MODE = Median = Mean. I am going into this not to teach you statistics but to get you to re-examine your expectations and the stick against which you are measuring performance. This is absolutely critical! Because if you are measuring against a false stick, you will never get your team to improve; in fact, you may have adverse consequences.

Here's the deal, the performance curve and probabilistic distribution say that you most likley have an average team with average individual performers. Every now and again, you will get lucky, but you will also get unlucky and get a dud. But you should plan assuming average performance by your human capability enablers. Planning assuming otherwise will result in a likley too optimistic, unachievable plan and is not much more than wishful thinking.

And since you cannot pick 'em, then you need to accept the level of performance you are getting and build internal quality controls to control defects and incrementally improve performance over time. Throwing a ton of money into trying to make a change under this dynamic is a waste. Any blip you might see may be nothing more than stochastic, with a return blip back to the mean (regression to the mean).

That said, the three leading drivers to performance are purpose, autonomy, and mastery. Make sure you understand what these are and starting building a culture that enables them. If you are experiencing a special cause in lower performance, this may help. (Making your team read a book, by the way, is not an enabler of any of these three.)

Answer 3

I think that most important thing is to answer question why do you need to make developers better. Is it because you want development to be realized better and more efficiently or do you want to have better developers that by the way will be doing development better? If only first one then there are two way of achieving this: a. Improving performance of team - which I believe is easier task - lot of methodologies - let's take SCRUM as example, might help in that case b. Improving performance of individuals - which apparently you want to do and what I believe is much harder

Let us assume that you want to achieve b.

In my opinion you should start from assuring that developers themselves feels need of improving their own way of work if they see that then your job Is lot easier, if not you need to change it. It is very hard to suggest way of motivating them, probably each team member is motivated by different factor. For sure I am not convinced that they are motivated because they are paid more than fair , in lot of situations money is not everything quite often it is responsibility, self-realization, having things under control, concrete and clear vision of future and so on..

Having people motivated to improve themselves you have more than half job done. Then lot of techniques mentioned in other answers should work quite nice. From my perspective two most important are: a) Frequent feedback - that comes from peer review, application demo, retrospective meeting or any other meeting/discussion that is about what happens in future and how can we improve it. b) Delegation of responsibility - initially you might be main feedback-giver but it should change rather quickly and team itself should organize around self-improvement. c) Slack - learning is painful process, and lot of errors must be done during that time, You must be patient and You shouldn't demand high performance and learning at the same time, idle time is necessary.

Answer 4

I realize you don't have hire/fire authority, but sometimes the really bad ones do need to be let go.

Have a look at the similar question: Handling unskilled / unmotivated team members

Answer 5

There is no "silver bullet" framework for software development.

Have you focused on the team to build a high performing team?

Some of the team building exercises that I have successfully used are:

1. Lyssa Adkins (Coaching Agile Teams) has a great team building exercise – high performance tree.

   o Uses the Scrum Values: Commitment, Courage, Focus, Openness (transparency) & Respect for team building.

   o Team identifies characteristics of a high performance team.

2. Facilitate Retrospective meetings for continuous improvement.

   o What is going well?

   o What needs improvement?

   o Let the team commitment to implementing 2-3 improvements.

3. Use a “WaterCooler” meeting to build the team in a casual sitting.

   o Casual meeting to play.

4. Use Persona for team members.

   o Helps people know the team members.

For distributed teams, I use the on-line tools Conteneo & Trello for meetings.

Example of a High Performance Tree:

Answer 6

First things first, decide on a methodology - many of those you mention are opposing and would not play well together. TDD, Agile, SCRUM - choose one (TDD may help here, but it can be a mind set change) :D

Next, it seems that QA is your real issue. This means you need to bring in some basic process changes. Look at old fashioned code walkthroughs - impliment a rules based "cop" to standandise code (many "cops" out there these days - and VS has it built in). If using VS, impliment a testing process in build, too (test cases can be built at coding stage and tested on the fly - some extensions even check as the code is keyed!). Make sure test cases are written by a different person than the coder, preferably a sys an/prog and with some experience (a good dev lead will help with this - if you don't have a dev lead, think about making one even if it's a no-payrise position from within the ranks), get more user involvement if possible to keep things on an even keel. Give the Dev Lead the responsability of ensuring the sec is fulfilled and test scripts are set up - let them work directly with the sys/bus analyst as well as mentoring the coder(s). Make users sign of designs/test scripts and "pay" for any scope creep. Have QA done within the team and signed off by you, that way the QA analyst, tester and coder all know that they are being monitored (fairly) - it also makes bug fixes cheaper as they will be caught earlier in the dev cycle.

Coders get better by experience and by learning good practices (via mentoring and osmossis) - if the team has no one of that calibre on it, maybe you need to push for a hiring of a dev lead position (or borrowing one from another project perhaps) to do just that - the PM can push, but it takes another coder to show how it should be done.