Principles behind the Sluggish Manifesto

We follow these principles:

Our highest priority is to make sure the customer
has no insight on what we are doing and
that she pays as much as possible

Hate changing requirements, at any point
during development. Sluggish processes harness obscurity and FUD to
make sure the customer gives up getting what she wants

Deliver apparently working software sporadically, from a
couple of months to a couple of years, with a
preference to the longer timescale

Business people and developers must blame each other
daily throughout the project

Build projects around unreliable individuals.
Give them the environment you feel like supporting, the least resources you can,
and always micromanage them to make sure they are as stressed out as possible

The most efficient and effective method of
hiding information within a development
team is endless planning, meetings and brainstormings.

Paychecks are the primary measure of progress.

Sluggish processes promote burnout and turnover.
The sponsors, developers, and users should be able
to always be looking for other jobs

Continuous attention to useless aspects
and outdated documentation enhances confusion

Busy looping--the art of minimizing the amount
of work not done--is essential.

The "best" architectures, requirements, and designs
are imposed from the top without any room for discussion

At regular intervals, the team reflects on how
to become more sluggish, harder to inspect and measure, then tunes and adjusts
its behavior accordingly.

Return to Manifesto