Ken Orr wrote ( in Cutter IT Journal Vol.3, No. 7 ):

Agile . since Jun 23 . Index . DOCs TOP TOC

The 40-Hour Week


Agile development gurus preach that software development is more like a marathon than a sprint. In knowledge-based work, it is important that the individuals that make up the team be as fresh as possible. Although there is not much that software development managers can do to help team members avoid stress and burnout at home, they can certainly do so on the job.

The rule, then, on agile development projects, is that people in the normal development cycle only work 40 hours a week. Though there may be occasions for overtime, there shouldn't be overtime worked more than one week at a time: in other words --no death march projects.

Agile . since Jun 23 . Index . DOCs TOP TOC

The On-Site Customer


States Beck: "A real customer must sit with the team, available to answer questions, resolve disputes, and set small-scale priorities. By 'real customer,' I mean someone who will really use the system when it is in production" [1].

There is an old joke about involvement versus commitment: if you're fixing bacon and eggs for breakfast, the chicken is involved, but the pig is committed. This is absolutely true of the customer/user on an agile development project. People who are going to be using the system are responsible for defining how that system is going to work, and their commitment is for the period of the entire project.

The total commitment of the user is one of the major hallmarks of an agile development project. Users are as responsible for the definition, user interface, review, test case presentation, and prototyping of the end product as anyone on the team. Because of this, there is very little finger-pointing when the product is delivered for broad installation and use.

Agile . Index . DOCs . TOC