We may not know much about the requirements; our backlog may be slight; but we do know this about that:
1st requirements paradox:
2nd requirements paradox:
- Requirements must be stable for reliable results
- However, the requirements always change
- We don't want requirements to change
- However, because requirements change .... is a known risk, we try to provoke requirements change as early as possible
So writes Niels Malotaux in an interesting 16 page paper describing his version of Agile, titled: "Evolutionary Project Management Methods: how to deliver quality on time in software development and system engineering projects".
Here's what Malotaux calls "Magic Words"
Developers tend to be easily distracted by many im-
portant or interesting things. Some things may even
really be important, however, not at this moment.
Defining priorities and only working on the highest
priorities guides us to doing the most important things
• Synchronise [sic]
Every project interfaces with the world outside the
project. Active synchronisation [sic] is needed to make
sure that planned dates can be kept.
This word forces us to define the reason why we
should do something, allowing us to check whether it
is the right thing to do.
• Dates are sacred
In most projects, dates are fluid. Sacred dates means
that if you agree on a date, you stick to your word.
To make estimation, planning and tracking possible,
we must finish tasks completely. Not 100% finished is
not done. This is to overcome the “If 90% is done we
continue with the other 90%” syndrome.\
• Bug, debug
A bug is a small creature, autonomously creeping into
your product, causing trouble, and you cannot do
anything about it. Wrong. People make mistakes and
thus cause defects. The words bug and debug are
dirty words and should be erased from our dictionary.
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog