Our Post-Agile World


It’s been a looooong time since I’ve posted anything about Agile, and today I sat down to try and figure out why. It’s not that I don’t care about the values in the Agile Manifesto, nor that I’ve gone completely over to Zed Shaw’s manifesto.

It’s not that I’ve found Lean/Kanban to be the end-all be-all, although I really love the simplicity in the approach (with a lot of back-end difficulties around being forced to ask tough questions).

You can code really well, but produce software that no one uses. You can produce really crappy software that a lot of people use, but then is hard to change in the areas the business desperately needs it to.

Instead, it seems that our company these days has focused on a couple things that tend to make some of the other ideas, just not as important. Or not TOO important. What we’ve settled on as our overriding philosophy of what our goal is are two-fold:

  • Deliver released value early and often
  • Don’t surprise the users or the clients

Releasing early and often forces a lot of other practices in place, with a specific goal in mind (deliver value).

No surprises is around setting expectations, having the conversations to figure out WHAT should be built.

No surprises = figure out WHAT to build, WHEN it will be delivered, and actually deliver it. Commit to what you can, set expectations on what needs further refinement before commitment.

Deliver early and often = Mitigate risks by making sure working software is actually in production as quickly as possible. Long release cycles are hugely risky, and have a greater chance to screw up, therefore negatively surprising the client.

Good surprises are a risk too! That “surprise” feature is good for new users, but the business owners shouldn’t be surprised by the feature you decided to also include.

With these two guiding principles in place, all of the practices around XP, Scrum etc. sort of become tools in the toolbelt that can be used, sometimes, when they help with delivering without surprises. Otherwise, they can be a waste.

Looking back again on why I’m just not interested in Agile any more – it’s not that I don’t find value in these tools, but I get tired of discussions that don’t involve context of WHEN these practices are useful. Too often it’s black and white (i.e. the term ScrumBut) and not a real look on whether these practices ACTUALLY add value.

Because it comes back to just one thing: Are you consistently delivering value to production without surprises?

Extra credit: Go read The Goal, right now, if you haven’t already.

Eventual consistency, CQRS and interaction design