Recommend resources for development team leaders

Question

I was recently made the team leader of a database (95% MS SQL Server, 5% misc-Oracle, Sybase, Access) development team that manages and develops a large number of databases in a corporate environment. I'm looking for resources (checklists, utilities, best practices, procedures, websites, books, etc) that will help me to implement fundamentals which have been lacking in this development group in the past, such as code reviews, cross training, documentation, enforcing standards, knowledge sharing, mentoring and so forth.

Most of what I'm finding is general management skills resources, but I would like to find anything that might be specific to leading a team of developers. Corporate processes are "standard" waterfall type SDLC, so resources geared towards Agile are not nearly as relevant.

Answer 1

Books I've bought & recommend for Tech Leads and Manager's who have worked for me:

Rapid Development (S. McConnell) - great "bible" of answers to common management/lead type things (more management tho)

Becoming a Technical Leader (Gerald Weinberg) - a dense read, but a great one.

Manager's Toolkit (Harvard Business Essentials) - again, more management focused, but good with some of the interpersonal issues

Collaboration Explained (Jean Tabaka) - more Agile focused, but another good bible of "how to do X" very practical

Beyond that... listen. Learn from your team. Learn from your peers. Learn from your boss. Find a mentor outside your chain of command but someone you respect and can run to when you get frustrated or stuck. Meet with them once every two weeks for breakfast.

Answer 2

I've just read Peopleware recently and found it very enlightening. It will definitely help you understand development team dynamics (and a lot of the mistakes we make in managing/leading them). I was recommended it by someone here on programmers.

Answer 3

Have a look at "Debugging the Development Process" by Steve Maguire.

Although it's not the most modern book any more (1994), it still has a wealth of information that should prove useful to you as a team leader and you can pick it up real cheap. I found it to be excellent.

You might also want to consider "Rapid Development" by Steven McConnell. Again, it's an oldie (1996) so it sort of predates the Agile methodology work so you'll find "waterfall", "spiral" and "timeboxed" approaches being discussed on their merits. You'll find some of the precursors to the Agile approach (Rapid Prototyping and so on). Also, in regard to "Best Practices" you'll find a huge range summarised on page 400 along with proper cited evaluations regarding their efficacy and detailed explanations within.

Both books are issued by Microsoft Press so should present sufficient reference with your existing technologies.

Most importantly, both books cover how to manage software development teams - motivation, scheduling, strategic thinking, leadership and so on.

Answer 4

I am in a similar position. The first thing is you define how the team should work, what processes should be in place, what is the role of the team. Create a wiki (or sharepoint or whatever) page to put all these. Then have lots of regular conversation within the team to define in detail each one of these. The one thing that is important is is to set a culture and behaviour that the team wants to have. For team knowledge this is what we use. Start a regular fortnightly or monthly knowledge sharing session, create a spreadsheet with various areas of knowledge in rows and team members in columns. Then assign a score from 1-5 to know the strengths and the gaps for each member. Make a plan assign primary, secondary and tertiary responsibility for each area with a target score of 5, 4 and 3 respectively.

Documenting all your processes is very important. e.g. We have a code review process and checklist. If processes involve other teams raise that with management and agree to processes at that level. e.g a release process.

I cannot stress the importance of documenting (can be lightweight in a wiki) as you have a strong baseline position to improve and demonstrate the management. Many a times my team has won in eyes of senior management because we had strong document and processes in place.