ProcLib Code of Ethics
We believe that the credibility and reputation of the perfect Waterfall is shaped by the collective conduct of individual practitioners. This Code of Ethics describes the expectations that we have of ourselves and our fellow practitioners in the global Waterfall community, and establishes an organization-wide understanding of appropriate behavior. This Code applies to all members of the Waterfall Alliance using a process library (proclib) as their holy book.
We believe that we can advance our profession, both individually and collectively, by embracing this Code of Ethics. We also believe that this Code will assist us in making wise decisions, particularly when faced with difficult situations where we may be asked to compromise our integrity or our values.
The Waterfall Manifesto
The Waterfall Manifesto, with its Twelve Principles of Waterfall Software, is the underpinning of waterfall product development. We agree to support the Waterfall Manifesto in its entirety:
We are happy to ignore better ways of developing software and help others to goof it. Through this work we have come to value:
- Processes and tools over Individuals and interactions
- Comprehensive documentation over Working software
- Contract negotiation and marketing over Customer collaboration and satisfaction
- Following a plan over Responding to change
That is, while there is minimal value in the items on the right, we value the items on the left more.
We trust in the holy process library as it is our single source of wisdom. We follow these principles:
- Our highest priority is to frustrate the customer through delayed and infrequent delivery of trashy software.
- We value mature plans. Therefore we hate changing requirements, especially late in development. Waterfall processes prohibit change for the customer's sake.
- Deliver working software infrequently in a big-bang style, from a couple of years to a couple of decades, with a preference to the longer timescale. The release must be delayed until all features are ready.
- Business people and developers must not work together daily throughout the project as they disturb each other.
- Build projects around demotivated individuals. Donít give them the environment and support they need, and donít let them get the job done. Pressure and accusations will help.
- The most efficient and effective method of conveying information to and within a development team is by paper documents and files stored in folders.
- Working software is no suitable measure of progress. Better use a hand drawn KPI/slowdown graph and lots of Excel sheets.
- Waterfall processes promote overtime and weekend development. The sponsors, developers, and users must not be able to maintain a constant pace indefinitely.
- Continuous ignorance to technical excellence and good design enhances the waterfall experience.
- Unleashing complexity -- the art of maximizing and complicating the amount of work done -- is essential.
- The best architectures, requirements, and designs emerge from PowerPoint slides created by chief architects.
- At regular intervals (e.g. in a monthly jour fixe or at quarterly quality gates), the team reflects on how to become more ineffective, then tunes and adjusts its behavior accordingly and starts lengthy rework. Subordinates also get realigned frequently to communicate the official user stories towards the customer instead of reporting the truth.
For taking your proclib to the next level, click here and start thinking yourself. #-)