Why are some teams more efficient than others?  Even those hand picked with the best developers can still be slow.  Sure, skill sets and individual aptitude can vary between projects but most of the time the development environment, including management, is to blame.

Why? Usually it's because the project has not been set up with rapid development principles in mind, principles which have been well known for fifteen years.

Signs of a problem:

  • Unstable application from the beginning.

  • High defect rates.

  • Unproductive team.

  • Regular alerts in the standup “I was stuck for the afternoon trying to work out how to do X”

  • Low team morale.

  • A long time between making a change and seeing the result.

  • Working weekends.

  • Long hours from early in the project.

Causes of slow development:

  • Slow builds.

  • Unreliable builds.

  • Unreliable source code control (too many branches).

  • Network problems

  • Computer problems like corporate lock-down or outdated OS.

  • Too many documents.

  • Unnecessary modularization where packages would have sufficed.

  • Lack of code-by-examples.

  • Too many new technologies. Restrict to one or two per project, and have a backup plan if they don't work.

  • Context switching or changes in scope while work is in progress.

  • Lack of autonomy, the ability to do the work without external dependencies.

In this chapter:
    [rapid.build] Tame your build
blog comments powered by Disqus