(based on
http://agilemanifesto.org/principles.html)
We follow these principles:Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
(We are not users of the systems we build, and shouldn't keep putting features in only we want. Which users care if it is OAIS compliant? And METS?)
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
(Go where the users are or want to be in terms of features, not where you think they should be. Users should be shielded from the underlying standards at
ALL times.)
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
(If you are not going to implement what you are designing and learn from it as you progress, then you have
failed. Do not pass Go, hand in your library pass.)
Business people [USERS] and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
(Don't just list projects you want doing and expect them to be done. Find people doing work the
community finds compelling or interesting and fund them directly.)
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
(More working meetings, fewer dissemination meetings. Discussion, not powerpoint.)
Working software is the primary measure of progress.
(No plan should get the go-ahead, without implementing the ideas or design alongside it.)
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
("Projects" lead to having concepts like 'final deadline' and 'wrapup meetings'. Repositories are, by their remit, continuous
services, and
DO NOT FIT the project paradigm.)
Continuous attention to technical excellence
and good design enhances agility.
(Can't simply work on architectual astronomy without trying to implement, can't simply code and build without a valid design choice. Not one or the other, but working on both simultaneously makes for a good service.)
Simplicity--the art of maximizing the amount
of work not done--is essential.
(Re-use, re-use, re-use. We only need one good system, not 5. In all development, there is time for divergence and a time for convergence, and it's time we converged. Shame there's no good candidate to move to...)
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
(No design is static and no implementation is static, only your current users are. Build and cater for the users you do have, and aim to please those you don't.)
