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 when hiring.
  • 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 developers 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 (JIRA, 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
    • Set 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