“Being Agile” is not a business outcome, it is simply a means to an end.

We do not mandate any specific methodology in our deliveries and actively discourage tribalism, dogma and cargo cult – where people blindly follow a practice, without understanding how it delivers outcomes. We have sufficient mastery of agile to employ a toolbox approach, carefully applying the pieces that will deliver most value – no practice is so important that it can not be questioned, or adapted, in order to meet the desired outcome.

The important thing is to establish short feedback cycles, continuously improving (or failing fast), and constantly iterating, towards a shared definition of success with the customer.

We are not precious. Reaching the best outcome for our customer always matters more to us than the way we get there; if we really have to choose, we will build the right product over building the product right. There are times (always performed with the customer’s explicit understanding and approval) when software is produced which doesn’t meet our preferred standards. And there are times where software is not the best solution.

More often than not, reaching a positive outcome does require us to ship technically robust code. But we are careful to avoid getting ourselves into a “build trap” or “feature factory”, where we deliver feature after feature without clear understanding of the outcome. To avoid that, we invest time in uncovering the right problem to solve, not just doing what the customer asked: we deliver outcomes over features.

Everything we do is delivered with a healthy dose of pragmatism. This does not mean that we will sacrifice our other values for expediency, but it does mean we avoid hard and fast rules that offer little return for disproportionate cost.