On 17/07/07, J. B. Rainsberger <jbrains762@...> wrote:
> Why should agile /require/ TDD? TDD is a design activity. Does agile
> care how I design software? I thought agile was mostly concerned with
> issues like early realization of value and predictable delivery. Surely
> TDD is optional but recommended.
> --
> J. B. (Joe) Rainsberger :: http://www.jbrains.ca
I like the notion of "early RoI" and "metronomic delivery" forming
part of a black box definition of Agile. The black box definition
seems to be an embodiment of the customer's bill of rights. Therefore,
to a customer, a development method could be considered Agile if...
- It allows the customer to plan on a large scale with costs and options.
- It allows the customer to set development priorities weekly.
- It allows the customer to see progress in the form of a working
system at the end of the first week, and to see a little more
functionality every week thereafter.
- It allows the customer to get updates on the schedule, good or bad,
as soon as the information is available.
- It allows the customer to change his/her mind without paying exorbitant costs.
So in theory, to a customer, nothing else should matter, as long as
the process seems agile to them.
To a Manager, we have the grey box. So a development method is Agile if...
- It affords the manager an overall estimate of costs and results,
recognizing that reality will be different.
- It allows the manager to move people between projects without paying
exorbitant costs.
- It allows the manager to get monthly updates of progress, and to
help the customer set overall priorities.
- The manager has the right to cancel the project and be left with a
working system reflecting the investment to date.
To a developer, we have the white box view of Agile. So to them, a
development method is agile if...
- It allows the programmer to estimate work and have those estimates
respected by the rest of the team.
- It allows the programmer to honestly report progress.
- It allows the programmer to produce high-quality work at all times.
- It allows the programmer to know what is most important to work on next.
- It allows the programmer to ask business-oriented questions whenever
they arise.
Each of the definitions is inadequate in itself. Perhaps we need to
acknowledge that Agile looks different from different angles.
--
Regards,
Tim Haughton
http://www.timhaughton.info
The Agile Micro ISV Blog