The Web Gambit

Thoughts on Web Development

Lead Developer Techniques

Joe Ocampo had a great post where he gave his checklist for an effective Agile Development Manager.  I think that many of the points he makes are very relevant for even non-Agile development managers too.  And while I agree with most of what Joe is saying, there are a few areas that I want to expand on.

1. You have to be a developer yourself.  If you don’t know how to code don’t manage developers period!!!!  And knowing COBOL doesn’t count!

I agree with this wholeheartedly.  However I would expand this to say that while a lead developer should be up to date with their skills to provide guidance to the other developers, the lead should also recognize that the others may find a better technique for a particular area of the project.  The lead should be willing to try the new technique rather than only use familiar techniques.

2. You have to manage the team not the individuals.  Think of yourself more as a coach not a manager.  Maximize your assets by understanding your team’s weakness and strengths.

3. If you have mediocre programmers (first off yikes!) second as long as they show a willingness to learn, paired programming is the key to success for bringing the juniors up to par with the seniors.

Let’s face it, it’s not always realistic to fill a team with Spartan Developers.  Since teams always have varying skill sets, it is very important to quickly assess where all the team members stand to determine which tasks are most appropriate for them.  All too often I’ve seen situations where a developer is assigned a task that is beyond their skill set and they can’t complete it in time.  Depending on the task’s visibility, such things can linger for weeks before it becomes apparent that the developer should have been given some help to complete it.  While the pair programming method can help alleviate such issues greatly, a good lead should take the time to recognize the team’s talents and make sure tasks are assigned accordingly in the first place.

4. Empowerment, allow EVERYONE to take ownership of stories and task.  If a junior wants to take on a story or task let him/her role with it.  Your TDD practices along with the pressure from their peers will make certain it is done correctly.

Completely agree with this point. A good process should allow plenty of opportunity for individuals to take ownership of difference pieces of the project.  Most teams with a good process are also very good about policing themselves. E.G.,  I’ve seen a lot of interest techniques on how to punish the person who broke the build.

5. Embrace the fact that your team need to understand their goals!  What they are playing for?  What is the goal for the week (Velocity, Stories)?

This is possibly the most important point on the checklist.  A team cannot work well if everyone doesn’t understand the big picture and the business problem that is being solved by the project.  Also it should be easy for any team member to map every one of their tasks correlates to a relevant business problem.  If individual tasks do not easily map to an understood business problem, then the development process is broken and should be re-evaluated.

6. They need a way to measure and understand if it is first and ten or fourth and twenty?

Hammering on a set of tasks with no end in sight can de-motivate even the most productive and task-oriented developer.  Everyone needs consistently measurable progress. 

7. Coach them every day!

Daily feedback is something that Agile techniques like SCRUM emphasize a lot.  The key thing to understand here is that coaching doesn’t always have to be at the individual level.  A simple email to the whole team saying “Good job on that last sprint!” might be all that’s needed to effectively fulfill your coaching quota for the day.

8. Get rid of your heroes or code hogs!!!!

This is the one point where I don’t agree with Joe.  If one of your developers is being a code hog or causing dissension within your team, it’s because you aren’t sufficiently challenging or motivating them.  Also if you aren’t respecting their opinion then you are only feeding the fire of team dissension.  Address it by understanding their goals/motivations and utilizing them more effectively.  Dumping your Hero is the last thing you want to do.  The simplest way to deal with a Hero is to give them ownership of a particular area and respect their opinion when its warranted. And if you find reason to disagree with them, clarify your points rather than simply pulling rank.


Comments are closed.

%d bloggers like this: