Skip to content

The Dandori Manifesto

Download the Manifesto as PDF

段取り

We are discovering better ways of building software by recognizing that how teams coordinate matters as much as how code gets written. Through this work, we have come to value:

Precise specifications over ambiguous stories

Pipeline visibility over sprint commitments

Decision speed over estimation rituals

Preparation quality over production volume

Flexible constraints over unchecked permissiveness

That is, while there is value in the items on the right, we value the items on the left more.

Principles Behind the Dandori Manifesto

  1. The specification is the unit of work. It serves simultaneously as the design document, the execution instruction, the review criteria, and the team communication medium.

  2. Human judgment is the scarce resource. Every ceremony, role, and practice exists to amplify and protect human judgment, not to optimize labor allocation.

  3. Preparation determines quality. The quality of the output is determined by the quality of the specification, not by what happens during execution.

  4. A framework must restrict as well as flex. If adoption can mean anything, adoption means nothing. Certain elements are non-negotiable because removing them breaks the quality model.

  5. The best synchronization point is the artifact, not the calendar. Disciplines converge on the specification, not on a sprint boundary. When the spec is complete, everyone has already agreed on what "done" looks like.

  6. Visibility is not a report. It is the system's state, observable by everyone at all times. No party should control the narrative when the pipeline is transparent.

  7. Ceremonies earn their place by addressing specific failure modes. If a ceremony does not prevent a real problem, it is waste.

  8. AI is a team member, not just a tool. The coordination model must account for participants that execute at machine speed while humans think, decide, and validate.

  9. The framework works with or without AI. It is a response to the modern reality of software delivery, of which AI is one part but not the only part.

  10. Teams of any composition can adopt Dandori. Designers, architects, QA engineers, business analysts, and any other discipline contribute to the specification before execution begins, not on a parallel timeline.

  11. Metrics must translate into business language. Engineering health metrics are necessary but not sufficient. The business deserves answers to "when," "what if," and "what is the risk" grounded in pipeline data, not estimates.

  12. Start with everything, reduce based on evidence. Dropping a ceremony because you are too busy is avoidance. Dropping it because your data justifies it is earned confidence.

Dandori: Preparation is the work.