The PRISM Manifesto

A wake‑up call for dysfunctional teams in an increasingly fragmented industry, with the aim to encourage each other to build better software.

Our guiding principles:

Respect people and open communication above processes, platforms, or tools.
Seek genuine collaboration rather than ceremony.
Embrace change rather than rigidly adhere to a plan.
Focus on working software instead of performative complexity.
Document decisions, intent, and meaning instead of encyclopedic detail or auto‑generated noise.

We...:

Test our assumptions first: thoughtfully, meaningfully, and domain‑aligned.
Deliver something useful frequently, in small, stable increments.
Accept changing requirements — even late — as a sign of learning, not failure.
Encourage developers, stakeholders, and users to work together closely and candidly.
Build projects around motivated, trusted people, so that both will thrive.
Communicate directly and personally, rather than engage in asynchronous bureaucracy.
Measure progress in outcomes, not in tickets, charts, or rituals.
Maintain a sustainable pace; Essential for quality, safety, and long‑term success.
Apply technical excellence and good design principles as non‑negotiable foundations.
Pursue simplicity to minimise work that isn’t necessary.
Organise our team around problems, not through imposed patterns or processes.
Reflect regularly and honestly to learn from our mistakes and improve our craft.

This manifesto may be freely copied and distributed in any form, but must include the entire unaltered text, this copyright notice, and be attributed to Perridak Software.

You are welcome to discuss PRISM, ask questions, or offer opinions via our PRISM Discussions Channel on GitHub.

F.A.Q.

Why the name PRISM?
In optics, a prism can expand light, breaking it into colour frequencies and enabling us to understand how light is made up of smaller components, which is an elegant metaphor for both software development and problem-solving. A prism used from another angle can also intensely focus light to a single point, which is also a beautiful metaphor for staying true to your purpose, and for the PRISM manifesto itself, to remain true to its intent. This bidirectionality of meaning is also really cool.

Why is PRISM always capitalised?
PRISM is also a flexible acronym. It was envisaged as being customisable so that teams can choose to encode their own words to define their intent and ethos, and make PRISM a meaningful word for themselves. This adaptability is what Agility was always intended to be conceptually, made manifest in an acronym that suits your own adoption of the PRISM principles.

We like to joke internally that PRISM says that Perridak Reliably Implements Software Masterpieces! However, for our software development process, we say that it is all about People - Reliability - Intentionality - Simplicity - Maintainability. This defines our purpose and keeps us mindful of the way we prefer to work.

Isn't PRISM just another stab at Agile 2.0?
When we created PRISM, we were inspired by Agile, but never intended to copy it. While there are certainly parallels, it isn't simply a rebrand or a reword. It's intended to address some of Agile's loose ends, and the very things that have made the word Agile lose its meaning in recent years. Agile was deliberately loose in its definition, yet that in itself is also a flaw that opened the doors to misinterpretation. Take the statement "Working software over comprehensive documentation", for example. Many proponents decided that this meant no documentation at all, or minimising documentation to the point of being effectively useless. Others have said that the code should document itself, and should be written so that it is self-explanatory, yet that is rarely ever the case in practice.

PRISM aims to be intentional, even as it encourages an agility mindset. We wanted to set clear principles and expectations without being overbearing. Agile was defined around values. PRISM is built around principles. It strives to avoid dogma even though it suggests guardrails. We feel it hits a sweet spot, as it defines an ethos without prescribing a strict process.

Is PRISM complete?
In some ways, no. Perhaps it never will be. The 3rd principle is to embrace change. We can't claim to have got this perfect first go, just as the Agile Manifesto and the US Constitution were great, yet over time have needed refinement. PRISM is meant to be a living and breathing concept that adheres to its own principles, so we expect that this will need improving at some point. Hopefully this will be without needing to wait another 25 years, but also without being changed just for the sake of change.

Are you trying to change the world, or get everyone to adopt PRISM?
No, that has never been our intent. PRISM was defined to set the standard for how we work at Perridak Software. If you agree with our approach, you are welcome to adopt the principles and adapt them to enhance your own processes. If you do, we hope you will tell us your story about how PRISM has helped you, and to share your story with others so that we can all learn from each other's successes, and also from our mistakes. This is one way we can work towards helping each other to combat the dysfunctionality that we see in software development teams, and in other industries as well. That said, it is neither expected, intended, nor mandatory, even though we encourage open and candid communication.