Some notes from a short presentation I gave on building quality software development teams:
- Effective teams start with good people. A business is not a charity and cannot wait for people to grow into the role required of them. Intelligence and inherent motivation cannot be taught. These and many other aspects must be screened for.
- But hiring good people is not enough. Getting the most of a development team requires certain environmental factors. I have organized them into three areas: internal/motivational, structural/organizational, and interpersonal/communication. Sometimes they will conflict with practical considerations, but we ought to take them consideration whenever possible.
Motivation
- Instill a sense of professional pride
- Developers should take part in the technical design
- Provide interesting, challenging work
- Developers should own the technical solution
- Technical architects should be part of the development team
- Respect the developer time
- Provide a quiet environment dedicated to development work
- Buy the best tools for the jobs – powerful computers, large monitors, etc.
- Reward learning and exploration
- Take (reasonable) risks with new technologies
- Schedule time for self-education and information sharing
- Create a sense of project ownership
- Delegation “ownership” of functional parts to individual people
- Assign developers responsibility for follow-up maintenance (don’t just hand it off to a maintenance team)
Structure
- Hold people accountable for their work:
- Use a work unit tracking system (TFS, etc)
- Make task status publicly visible
- Hold daily stand ups (Scrum)
- Consider a public scrum board
- Provide clear project requirements
- Lean development approach
- No time-wasting tasks (useless documentation)
- Isolate developers from unrelated tasks (no business interruptions)
- Hold high expectations
- Monitor quality of work with code reviews
- Regular training & information sharing sessions
- Consequences for bad work
- Set well defined deadlines
- Don’t set arbitrary deadlines, but all work should have a deadline
- Developers should have input on deadlines for their work units
Team Communication
- Instill a sense of collective ownership of the project
- Hold architectural education sessions
- High-bandwidth communications
- Entire team should work in physical proximity
- Make quality visible
- Use continuous integration and automated testing to provide immediate feedback of quality
- Developers should fix their own bugs
- Track quality over time
- Explicit mentor roles
- Mentor roles should be explicitly defined
- Mentoring time should be scheduled into the project