Did you know that many projects are delivered on time, on budget, and on scope… and are still considered failures?
That’s because they don’t satisfy the user. And that disconnect is exactly what many software laws have been warning us about for decades.

The Unwritten Rules of Software

Before agility was a thing, practitioners were already documenting the harsh realities of software development. These weren’t official standards or processes—they were empirical truths, learned the hard way, and observed so consistently that they became known as software laws. A few stand out:

• Conway’s Law – Software architecture mirrors the communication structure of the organization.

• Ziv’s Law – Requirements will never be fully understood until there is a working version of the software.

• Humphrey’s Law – People don’t know what they want until you show them something they don’t.

• Brooks’ Law – Adding manpower to a late software project makes it later.

These aren’t just fun quotes for talks—they reflect the reality of building things in complexity, where what’s supposed to work on paper falls apart in practice.

Why These Laws Exist

Because software isn’t predictable like traditional engineering. It:

• Changes constantly.

• Is highly abstract.

• Is based on rules we invent as we go.

• Is deeply affected by communication, expectations, and context.

And because of that, decisions have side effects. Bad practices don’t just delay timelines—they erode trust, waste resources, and burn teams out.

When Management Ignores Them… It Shows

According to the CHAOS Report 2015:

• Only 11% of Waterfall-managed projects succeeded.

• 29% completely failed (cancelled or delivered nothing).

• The remaining 60% were over budget, late, or missed scope.

And that’s because traditional management models operate as if the system were simple or complicated, not complex—they try to control it instead of working with it.

The Turning Point: 12 Principles That Changed Everything

In 2001, after decades of seeing these laws violated again and again, a group of practitioners came together to codify the antidote. The result was the Agile Manifesto, and more importantly, its 12 principles.

They didn’t come from theory—they came from practice.
From Conway, Ziv, Humphrey, Brooks, and thousands of unnamed failures.

The 12 principles and the 4 values are a distilled compendium of observations from the field. They recognize that:

• Change is constant.

• Value is more important than scope.

• Working software matters more than detailed plans.

• Collaboration beats contract negotiation.

• Reflection and adaptation are non-negotiable.

And that’s just a glimpse.

These are only a few of the ideas they capture—each principle holds layers of hard-earned wisdom gathered from real-world experience.