Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects / Edition 1by Richard Whitehead
Pub. Date: 06/28/2001
This book aims to provide help and advice for IT professionals in this situation by offering solutions to the most commonly encountered problems, such as getting a project out on time, coping with the demands of leading a team, implementing new methodologies or technologies. It is written by a team leader for other team leaders with a focus on practical advice… See more details below
This book aims to provide help and advice for IT professionals in this situation by offering solutions to the most commonly encountered problems, such as getting a project out on time, coping with the demands of leading a team, implementing new methodologies or technologies. It is written by a team leader for other team leaders with a focus on practical advice rather than management theory or process issues. It would be targeted at experienced software engineers, developers and architects who have been promoted to the role of team leader.
Table of Contents
Foreword by Shari Lawrence Pfleeger
THE NEW LEADER
1 I¿ve just been made team leader of a new project. Where do I start?
2 I¿m taking over the leadership of an existing project. Where do I start?
3 I am the most experienced engineer on the team. If I let others do the design and coding, they will not do it as well as I would. How can I do the important design and coding, if I am expected to write documents and plans all the time?
4 When should I review other people¿s work, and how?
5 When should I call a meeting and how should I chair it?
6 I have to interview a job applicant. How do I go about it?
7 How do I make a presentation?
8 How do I earn the respect of my team?
9 How do I draw up a project plan? What use is it?
10 I¿ve been told when I must deliver my project, but the time-scale doesn¿t seem realistic to me. What should I do?
11 How can I stop my project from coming in late?
12 My team is working closely with another team, but the quality of their output is poor. What can I do?
13 My last project never seems to go away, I¿m constantly doing fixes and changes to it. What can I do?
14 How can I get a good job done when our procedures are so bad?
15 What is meant by ¿teambuilding¿? Is there something I¿m supposed to be doing to build a better team?
16 Sometimes I think I¿m being a soft touch and letting people walk all over me. Other times I think people resent me for interfering. How do I know when I¿m getting the style right?
17 One of my team members is an expert in an important aspect of the project that I know little about. I feel like a fool trying to lead on this issue. What can I do?
18 I can¿t get my team to do any design or documentation, they just want to code. What can I do?
19 When should I let someone do a thing their own way, and when should I make them do it my way?
20 How many hours should I and my team be working?
21 I want to praise people when they do well, but it sounds so condescending. How should I reward good work?
22 I¿ve got someone on my team who¿s a real problem. What should I do?
23 I think one of my people is going to leave. How can I prevent them from going?
24 One of my team is spending too much time chatting and web browsing. What should I do?
25 What is meant by ¿requirements capture¿? How do I go about it?
26 The customer keeps asking for changes and improvements. Can I really say ¿no¿?
STRESS AND CONFLICT MANAGEMENT
27 I¿m very stressed at the moment, and so are some of my team. What can I do about it?
28 My team seems to spend too much time arguing. What can I do?
RELATIONSHIP WITH MANAGEMENT
29 I want to tackle the project in a particular way. How can I make sure that my management will let me?
30 My boss is useless. How can I put up with this?
31 I feel I¿m not getting the support I need from management. What can I do about it?
32 I constantly have to make decisions on the project, often with little time for consideration. How can I be confident that I¿m getting the decisions right?
33 I have to take a decision, and it involves taking a significant risk. How can I decide whether to take the risk?
ANALYSIS AND DESIGN
34 Is ¿analysis¿ really necessary, or can I go straight into design?
35 How do I decide on the best architecture and design for my project?
36 We have adopted an object-oriented approach, but everyone on the team seems to have a different idea about how best to use it. How should an object-oriented approach be used?
37 Several of my team members want to adopt a new technology on the project. Should we use the new technology or do it ¿the old way¿?
38 The design of my project is in a mess. The architecture needs restructuring, but there¿s no time to do it. What should I do?
TESTING AND PROJECT RELEASE
39 Should I concentrate on unit testing or final testing of my project in order to catch the most bugs in the least time? /
40 We¿re about to release our product to our customer. How can I make sure it goes well?
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >
Back in 2001, this would have been a great book. The management of software teams was still based on the assumption that what works in manufacturing and construction would work in software. This has since been shown to be a huge mistake. If you are still laboring away in a development shop that's stuck in the past, with a command and control management structure, a matrixed organization, and plan-driven project management, then this book will resonate with you. However, all it's advice will simply help you to handle the symptoms of a broken way of working. If you need to learn about truly effective leadership, then search for books and training in agility (Scrum, XP, Kanban, Lean, Crystal, etc.). These approaches are based on the discovered reality of how software development works. Whitehead's book is dealing with assuaging the symptoms without curing the underlying disease. I don't blame him, when he wrote it, it was all good advice. But we no longer use leeches or trepanning in medicine, we no longer hand-crank cars to start them, we no longer use lead in paint. We no longer run software development teams like this. So read it from a historical perspective - this is how it used to be in the bad old days - but don't read it to learn how to do a great job today. If you do read it, and find yourself nodding with recognition, then know that you are stuck in a dysfunctional workplace. Look for a new job!
This book is truly real-world and application specific. This book explains the gray areas of transitioning from Senior Developer to the role of Team Lead, the advice is realistic and sound. This is a great example of the job description that some managers 'neglect' to review with applicants being hired/promoted into this technical but rather managerial role. This book is on point with detailed illustrations of team lead scenarios, situations, and a plethora of how-to examples. The author does a marvelous job at relaying best practices and expectations of all around you, he speaks well on most ( if not all) aspects of the role of Team Lead. This book gives answers! Inspires Confidence to take lead or learn how to take lead of successfule software projects. Leadership can be learned and this book is the how to guide!