Leading a Software Development Team: A Developer's Guide to Successfully Leading People and Projects / Edition 1

Paperback (Print)
Buy Used
Buy Used from BN.com
$30.02
(Save 33%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 95%)
Other sellers (Paperback)
  • All (25) from $1.99   
  • New (8) from $35.02   
  • Used (17) from $1.99   

Overview

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.

Read More Show Less

Editorial Reviews

From the Publisher

"Fear not. This book will help you become an effective and respected team leader... the view from the trenches will help guide you in making your own decisions in the context of your own organization and its values... With Whitehead as your mentor, you can anticipate and diffuse problems. Soon you will be as effective as a team leader as you were as a developer" - Shari Lawrence Pfleeger "This is a book for the real world. Suppose you are the team leader of a software project. You thought you did all the right things at every stage. Yet the project came in three months late and the application crashed continuously when it went live. What could you have done to prevent this? This book gives the answers. Structured round common questions which should occur to every new team leader "How do I earn the respect of my team?", "How do I draw up a project plan?", it discusses the activities which you need to master" Donald Matthews, Project Team Leader, AIT

This is a book on how to cope with the dizzy heights of leadership without getting vertigo or offending everyone in sight.

Computing, August 2001

Read More Show Less

Product Details

  • ISBN-13: 9780201675269
  • Publisher: Addison-Wesley
  • Publication date: 6/28/2001
  • Series: Practitioner Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 368
  • Product dimensions: 7.28 (w) x 9.20 (h) x 0.74 (d)

Meet the Author

Richard Whitehead has lead a number of software development teams over recent years, and has a wide and varied experience in industries as diverse as diamond prospecting, medicine, communications, transport and digital mapping. He has worked for companies of many sizes and cultures from a high-tech start-up to a multi-billion dollar multinational.

Read More Show Less

Read an Excerpt

Why This Book Was Written

As software engineering matures as a profession, the position of team leader — the person responsible for the technical direction of the project and the work of the other engineers on the team — is becoming increasingly recognized as crucial to the success of a software development project. This book provides the help needed by team leaders to enable them to rise to the responsibility of leading a project. It is a practical book, containing tried and tested advice and techniques to help leaders overcome common problems, lead other people, make good decisions, and get projects out on time.

Who This Book Is For

This book is for anyone whose work involves both of the following:

  • making detailed decisions concerning the architecture, design or coding of software products, or performing hands-on software development;
  • leading, managing or mentoring other people who are developing software.
This book is especially relevant for someone who finds themselves leading a software development team for the first time, or who feels that their skills with people are not as good as their skills with technology, and wants some help and direction.

This book is most relevant for someone leading a medium-sized team, say 4 to 8 people. It should also prove useful, to a lesser extent, to the leader of a single-person project, or to a leader of a larger team or of a team of teams. This is a practical book for practising engineers. It is not intended to teach management theory, nor to contain the very latest thinking in every field. It promotes those practices that have been shown to work in the real world.

About Being a Software Team Leader

A really good software team leader needs to be totally competent with technology, and also very good at getting the best out of other people. It's a unique position, combining detailed hands-on software knowledge and skill, and yet requiring the leader to be able to step back from the details and see the broader picture.

The way that a team is led has a critical impact on the success of a software project. The team leader makes a vital contribution to the quality of the software, the appropriateness of the technical decisions made, and the quality of team-spirit and motivation that the team members enjoy.

Becoming a team leader forces you to have a different perspective on software development. As a developer, you know that you will be judged mostly by the quality of the designs and the code that you produce. But as a leader, you will be judged in two different ways:

  • By your bosses, you will be judged on how quickly and cheaply your project is completed and by how satisfied the customers or end-users are.
  • By your team, you will be judged on the soundness of your judgement and on the way you work with people.
This book aims to help you be better at these things and so to earn more respect both from your bosses and from other team members.

Leading a software development team can be stressful, and it can be risky. It might not be as stressful or as risky as, say, managing a football team; but it does share some of the same stresses and pressures of trying to satisfy many people who are hungry for success, with there being no prospect of getting a second chance if things go wrong.

Not surprisingly, it's a job that not many people can do well. The difficulty of the task makes it all the more rewarding when you know you are doing it well. Once you have led a successful project, you will want to keep doing it and you will want to keep getting better at it. I hope that you find this book useful in helping you to achieve and to build on success.

How This Book is Organized

The book is organized around real-world problems faced by leaders in their everyday work, such as 'how do I draw up a project plan?' and 'how do I earn the respect of my team?'. Many real problems have both people aspects and technical aspects, and the book approaches these together, as different dimensions of a given situation, rather than as completely separate issues.

However, as can be seen from the contents page, the sections have been collected into groupings according to the major aspect of each, so you can start reading about a particular aspect of the job if you feel the need to do so.

The individual sections are quite self-contained, and include references to other relevant sections and to the bibliography where relevant, so they can be read in any order.

About Job Titles Such As 'Team Leader' and 'Project Manager' in this Book

The software industry does not have a universally recognized set of job titles; they tend to vary from one organization to another. In this book, I have used the following job titles:

  • Developer: Someone who does the hands-on job of making software. Making detailed technical decisions, designing, coding, testing, documenting. May be responsible for their own area of development but not for the project as a whole.
  • Team leader: Someone who makes technical decisions concerning the architecture, design or code of a software project. Responsible for the technical success of the project as a whole, and for directing and reviewing the work of other team members. Critically responsible for the quality of the software produced. Has extensive and current development experience. May do hands-on development. On a small project, may act as Project Manager as well.
  • Project manager: A person who is responsible for planning, budgeting, liaising with management and negotiating with customers. May have technical training, but does not do development. In a larger project, or a multidisciplinary project, would direct the work of several Team Leaders. Critically responsible for the delivery of the project on time and within budget.
  • Software manager: The line manager for the developers. Responsible for hiring and firing, training and developing staff, also for procedures and working practices. Sets the strategic technical direction for the organization. Part of the management team.

If your work (or part of your work) includes the role of Team Leader as defined above, this book is for you. It doesn't matter whether you have been given responsibility 'officially', or you just find yourself leading other technical people because that seems the best way to organize things. It doesn't matter what your job title is.

The boundary between these jobs is not very distinct. Most team leaders do some development, and every team leader has to do some planning and other 'project management' activities. In this book I haven't distinguished between tasks on the basis of who should do them. I've just tried to give the best help with a task that I can, for those people who need it.

Contacting the Author

If you wish to comment on any aspect of this book, you can do so by visiting my website, http://www.richardwhitehead.com.

Acknowledgements

I would like to thank Robert Sander, Oemer Karacan and Donald Matthews, the reviewers of this book, for all their hard work and words of wisdom. Thanks to Mark Birdseye for giving me a copy of 'Why the Neanderthals Became Extinct'.

I am very grateful for the helpfulness and encouragement shown to me by everyone at the publishers, Pearson Education, who have kept me going and helped me to get it right.

Thanks also to my friend David Krause for his detailed reviewing, helpful criticism and late-night e-mails.

I must also thank my sons, Thomas and James, for tolerating all the times that Daddy spent 'scribbling' when he should have been playing.

Last but not least, I thank my wife Susan, without whose love and support I would never have completed this book.

Read More Show Less

Table of Contents

Foreword by Shari Lawrence Pfleeger

Preface

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?

PROJECT MANAGEMENT

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?

LEADING PEOPLE

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?

REQUIREMENTS CAPTURE

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?

MAKING DECISIONS

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?

41 Conclusions

42 Bibliography

APPENDICES

INDEX

Read More Show Less

Preface

Why This Book Was Written

As software engineering matures as a profession, the position of team leader — the person responsible for the technical direction of the project and the work of the other engineers on the team — is becoming increasingly recognized as crucial to the success of a software development project. This book provides the help needed by team leaders to enable them to rise to the responsibility of leading a project. It is a practical book, containing tried and tested advice and techniques to help leaders overcome common problems, lead other people, make good decisions, and get projects out on time.

Who This Book Is For

This book is for anyone whose work involves both of the following:

  • making detailed decisions concerning the architecture, design or coding of software products, or performing hands-on software development;
  • leading, managing or mentoring other people who are developing software.
This book is especially relevant for someone who finds themselves leading a software development team for the first time, or who feels that their skills with people are not as good as their skills with technology, and wants some help and direction.

This book is most relevant for someone leading a medium-sized team, say 4 to 8 people. It should also prove useful, to a lesser extent, to the leader of a single-person project, or to a leader of a larger team or of a team of teams. This is a practical book for practising engineers. It is not intended to teach management theory, nor to contain the very latest thinking in every field. It promotes those practices that have been shown to work in the real world.

About Being a Software Team Leader

A really good software team leader needs to be totally competent with technology, and also very good at getting the best out of other people. It’s a unique position, combining detailed hands-on software knowledge and skill, and yet requiring the leader to be able to step back from the details and see the broader picture.

The way that a team is led has a critical impact on the success of a software project. The team leader makes a vital contribution to the quality of the software, the appropriateness of the technical decisions made, and the quality of team-spirit and motivation that the team members enjoy.

Becoming a team leader forces you to have a different perspective on software development. As a developer, you know that you will be judged mostly by the quality of the designs and the code that you produce. But as a leader, you will be judged in two different ways:

  • By your bosses, you will be judged on how quickly and cheaply your project is completed and by how satisfied the customers or end-users are.
  • By your team, you will be judged on the soundness of your judgement and on the way you work with people.
This book aims to help you be better at these things and so to earn more respect both from your bosses and from other team members.

Leading a software development team can be stressful, and it can be risky. It might not be as stressful or as risky as, say, managing a football team; but it does share some of the same stresses and pressures of trying to satisfy many people who are hungry for success, with there being no prospect of getting a second chance if things go wrong.

Not surprisingly, it’s a job that not many people can do well. The difficulty of the task makes it all the more rewarding when you know you are doing it well. Once you have led a successful project, you will want to keep doing it and you will want to keep getting better at it. I hope that you find this book useful in helping you to achieve and to build on success.

How This Book is Organized

The book is organized around real-world problems faced by leaders in their everyday work, such as ‘how do I draw up a project plan?’ and ‘how do I earn the respect of my team?’. Many real problems have both people aspects and technical aspects, and the book approaches these together, as different dimensions of a given situation, rather than as completely separate issues.

However, as can be seen from the contents page, the sections have been collected into groupings according to the major aspect of each, so you can start reading about a particular aspect of the job if you feel the need to do so.

The individual sections are quite self-contained, and include references to other relevant sections and to the bibliography where relevant, so they can be read in any order.

About Job Titles Such As ‘Team Leader’ and ‘Project Manager’ in this Book

The software industry does not have a universally recognized set of job titles; they tend to vary from one organization to another. In this book, I have used the following job titles:

  • Developer: Someone who does the hands-on job of making software. Making detailed technical decisions, designing, coding, testing, documenting. May be responsible for their own area of development but not for the project as a whole.
  • Team leader: Someone who makes technical decisions concerning the architecture, design or code of a software project. Responsible for the technical success of the project as a whole, and for directing and reviewing the work of other team members. Critically responsible for the quality of the software produced. Has extensive and current development experience. May do hands-on development. On a small project, may act as Project Manager as well.
  • Project manager: A person who is responsible for planning, budgeting, liaising with management and negotiating with customers. May have technical training, but does not do development. In a larger project, or a multidisciplinary project, would direct the work of several Team Leaders. Critically responsible for the delivery of the project on time and within budget.
  • Software manager: The line manager for the developers. Responsible for hiring and firing, training and developing staff, also for procedures and working practices. Sets the strategic technical direction for the organization. Part of the management team.

If your work (or part of your work) includes the role of Team Leader as defined above, this book is for you. It doesn’t matter whether you have been given responsibility ‘officially’, or you just find yourself leading other technical people because that seems the best way to organize things. It doesn’t matter what your job title is.

The boundary between these jobs is not very distinct. Most team leaders do some development, and every team leader has to do some planning and other ‘project management’ activities. In this book I haven’t distinguished between tasks on the basis of who should do them. I’ve just tried to give the best help with a task that I can, for those people who need it.

Contacting the Author

If you wish to comment on any aspect of this book, you can do so by visiting my website, http://www.richardwhitehead.com.

Acknowledgements

I would like to thank Robert Sander, Oemer Karacan and Donald Matthews, the reviewers of this book, for all their hard work and words of wisdom. Thanks to Mark Birdseye for giving me a copy of ‘Why the Neanderthals Became Extinct’.

I am very grateful for the helpfulness and encouragement shown to me by everyone at the publishers, Pearson Education, who have kept me going and helped me to get it right.

Thanks also to my friend David Krause for his detailed reviewing, helpful criticism and late-night e-mails.

I must also thank my sons, Thomas and James, for tolerating all the times that Daddy spent ‘scribbling’ when he should have been playing.

Last but not least, I thank my wife Susan, without whose love and support I would never have completed this book.

0201675269P06182001

Read More Show Less

Customer Reviews

Average Rating 3
( 2 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(1)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Posted February 13, 2013

    Showing its age - only useful for team leads in out-of-date shops

    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!

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 25, 2002

    Lead, Follow, or Get the Hell Out Of The Way!

    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!

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)