Agile Is Just A Means To An End

Share
Reading time ~1

A couple of months ago I posted that software is just a means to an end.

Here’s an equally commonly lost point – in fact it’s almost identical.

Agile (or Lean, TOC, whatever) is a means, not a solution.

Our customers, users and stakeholders don’t want “agile”, they want “success”. Once they have success they’d quite like a means of making that success more repeatable but ultimately they simply want success.

We seek to promote our way of working (one of our goals as an agile community) but risk missing the actual goals of our stakeholders?

Our conversations should move away from Agile by name and onto:

  • how do we best attain our stakeholders goals?
  • how do we effectively identify those goals?
  • how do we attain consensus on what those goals are?
  • what do “success”, “good” and “OK” look like for everyone involved?

If we step back, agile is just a marketing term – a simple pattern for a collection of mostly proven ways in which we believe we can work effectively. Where we need that marketing or verbal anchor, let’s use it – (much like we’ll use whatever agile practices and culture we know are useful in attaining our stakeholders goals) – but let’s ensure we’re not having methodology and culture conversations for the sake of methodology and culture alone.

Before diving into “agile” discussions, step back and (re-)establish what success should look like for your customers and users from their perspective.

Readiness to Serve

Share
Reading time ~2 minutes

A couple of years ago a friend said: (I’m paraphrasing here)

My team are paid a huge pile of money to do nothing most of the time.

As an analysis team for a financial institution their goal was to be immediately available at the first sign of an anomaly in the system. Like every other good analysis team in the city, their goal was to identify and find a means of exploiting the next new anomaly before anyone else in the world did. When the rest of the world catches up, their edge is lost – until the next time.

Many times I see organizations saving pennies on billions of dollars of revenue to ensure they keep their teams “busy” or “fully utilized”.

  • If your teams are always busy, how will they be able to cope with the next bump in the road?
  • If your teams are always busy, how will they be able to stop and see the big picture?
  • If your teams are always busy, when will they have enough time to stop and sharpen their tools?
  • If your teams are always busy, who is looking around to see what the rest of the world is doing?
  • If your teams are always busy, who will you have available to exploit the next change in the market before your competition?

Unless money really is that tight, staff up your teams or balance your investment portfolio not just to deliver your current needs but also provide sufficient capacity to be “ready to serve” when the next anomaly hits your market.

Don’t Open More Barrels Than You Can Consume

Share
Reading time ~1

One of my colleagues is a Theory of Constraints guru so this stuff comes naturally to him but even so, his casual remark on a conference call not long after joining us stuck with the whole team. It’s now a poster next to my desk so that all my drive-by visitors can see his wisdom too.

“Starting more work doesn’t mean you’re going to get any more finished.”

My boss also repeatedly says:

“We need to see a few things 100% complete, not a pile of stuff 80% done”

I have my own pattern for this that I’ll be posting pretty soon – the title might be a bit of a giveaway.