Tips/tricks to manage a new team with new code [closed]

Question

How do you handle yourself in a new team where you are the senior most developer and most others in the team are junior to you by several years. The task ahead of the team is something nobody else including you has accomplished in their career before.

Management insists on higher productivity of the whole team, and as senior developer you are responsible.

Any tips for coming out trumps in a situation like this? Clearly, the entire team needs time to learn and let's not forget the team's new. However, deadlines are up ahead as well...

Answer 1

Don't let a tight deadline or the novelty of the project interfere with good engineering practice. Set-up a software repository, agree to a coding style, come-up with a test suite, etc. The newness of the task shouldn't be that big of a deal as long as you have quality people under you that are willing to work hard and learn the task ahead of them.

Or to put it another way: you were put in charge because the management believes that your background and experience has given you the tools needed to build quality software. Don't suddenly forget your skills just because this task seems daunting now.

Answer 2

First things first, start using a source code control system from the very first line of code. Get in the habit of checking code in early and often.

Second, decide on a testing strategy. Of course that should mean unit tests, but you should also consider how to automate acceptance tests.

Third, establish a continuous integration server so that your code is built regularly and tested regularly.

Once you have that, as a team establish some simple coding standards. You want your code to be easily readable by everyone. It doesn't really matter what the standards are. Indent with tabs, indent with spaces, curly-brace on the same line, whatever. It doesn't matter what they are, only that everyone consistently applies them.

Since the team is mostly junior developers, plan on reviewing code often to make sure they aren't adding too much technical debt to your system.

Finally, consider using SCRUM. If you do, hire a coach or go to some training. Since you are all doing something you've never done before, establishing realistic deadlines is simply impossible. With SCRUM, your management will have visibility into what you do on a daily basis so they can see what progress is (or isn't) being made. And, since your deadlines were apparently given to you, SCRUM at least guarantees that if you can't meet the deadline, at least you're delivering completed stories on an incremental basis, which arguably is better than coming to the end with a giant system that doesn't work at all.

Answer 3

In addition tothe answer by @chrisaycock... Do not underestimate the time you will need to allocate for mentoring/training etc. As the lead, you will need to learn to let go of the detail and trust your team. Your job is to become the enabler, road block remover, and run interferance when management poke there heads in. In a "normal" team, at about 7 or 8, the lead no longer programs, In your situation, this drops to 3 or 4 (Maybe even less), You are not a programming resource for the project.

Answer 4

Focus on communication in two areas.

1) As you and the team members gain a better understanding of what's involved (nearly always "more than originally thought", it's key to spend a lot of time explaining this to management. There are few real deadlines. I usually say that a NASA probe to an asteroid that will be in a certain orbital position only once every 200 years, now that's a real deadline. Other than that most deadlines are artificial and often not based on the work. They usually sound fixed becuase "we've only got that much money", "programmer bob leaves in 2 weeks", "We have to present to investors next week". However, if the work isn't done, then these deadlines get missed. Then what happens - reevaluate and decide what to do then. In reality management would rather get that "bad news" up front. It isn't easy to do this, and that's one reason this job is hard. If meeting the deadline mean cutting features then go over that. The one thing you're trying to avoid in all this is quick code to make a deadline. That's the beginning of the end of a code base that will not last well and the beginning of technical debt that chokes.

2) Inter-team communication. Set up formal practices like Bryan and others recommend. Make sure that you meet regularly as a team, e.g. once a week in addition to daily scrums. Gain respect and trust by listening, your most important tool. Make sure you focus on helping. Avoid negative criticism at all costs. When necessary use positive criticism and encouragement, e.g. "that is great, once thing you might want consider is X" over "that is not what we need, you need to do X instead"

Answer 5

What I have done is identify the capable ones and divide and conquer. I take the top 2 or 3 and make them captains. The others are then evenly split up into teams following the captains to their own little teams.

I give the captains chunks or modules to do of a program.

The captains give the newbies smaller programming or research tasks all the while explaining themselves what they are doing so mentoring happens while doing.

I try to arrange the room so everyone is in the same open space but each team is has their own circle of computers. I like to be in yelling distance to everyone so things move quickly.

This works well for about 10-20 programmers so far. The smaller groups are just better being in one group and I have not worked with anything larger yet.