Invariant 4: Do What You Said You’d Do In Invariant 3: Don’t Build Without a Plan, we wrote a lot of code. In fact we wrote all the code. Because we had a strategy and spec that included the requirement that no bugs were allowed in the code base, we’ve really covered all our bases and
Invariant 3: Don't Build Without a Plan In Invariant 2: Don’t Design Without a Strategy, we ended up with a spec and schedule. We could have ended up with a number of other artifacts, but we at the very least ended up with a spec and schedule. That spec and schedule means you have a PLAN,
Invariant 2: Don’t Design Without a Strategy In Invariant 1: Think, Then Do, we ended up with a strategy document of some kind. This strategy has been vetted by the team, and everyone remembers the snappy calls-to-arms, knows the general direction to take the product, and how to tell if the product is winning or not. So
Invariant 1 - Think, Then Do The first invariant is to: Think, Then Do. This aligns with the “Strategy” atomic unit discussed in the introduction. In order to understand this and future invariants, it’s best to understand the underlying principle behind the atomic units and why they are organized the way they are. As a
Featured An Introduction to the Invariants of Building Software An Invariant is a motto,a guiding light that–no matter where you’ve found yourself in the agile to waterfall spectrum, and no matter the rituals your product team follows–will help you ship quality software consistently.
