Some notes about “Agile is not just about software” article


Leon Tranter provides solid reminders about why Agile is not just about software but requires change in the whole organisation: business, people management, funding, accounting, marketing, product and not project management, risk management, and of course software development and maintenance.

Below you find some extracts, that I think are the key points, from his article.

Time have changed

We live in a completely different world than the one we lived in 30 years ago, let alone the one we lived in 90 years ago. But we still structure organisations, manage projects, choose strategies, hire and reward people, draw up budgets and fund work the same way we did 90 years ago.

  • Almost all of the valuable work people do now (in developed economies) is creative, collaborative knowledge-based work
  • Building software is not a repeatable manufacturing process, it is a bespoke creative design process
  • We live in a globalised economy with almost no barriers to the movement of ideas, people and money
  • Technological change is disrupting not just companies but entire industries, sometimes in just a handful of years
  • Time to market and customer value trump all (ALL) other metrics or priorities.
time passes

We need to change the way organisations work

And the values and principles of the Agile manifesto are a great starting point for doing that. Why? Because they focus on time to market and delighting customers. Not stakeholders: customers.

Stakeholders don’t make or break the company, customers do. And stakeholders rarely know what customers want. Product owners often don’t either, which is why you need to release software as quick as you can and watch what they do and find out what they want.

We need empowered self-organised teams

Contrary to popular belief, the US military is not a shining example of a big hierarchical organisation with strict chains of command. They’re smart and they know that doesn’t work in the chaos of war. Form many small units of smart empowered cross-functional teams, give them some high-level objectives. Then give them the freedom to adapt to their situation and find the best way to get the job done.

We need to treat people with respect

No more treating technology people as strange nerds to be mistrusted and micro-managed. We need to hire really good people and reward them appropriately. […] by giving them freedom, autonomy, and buy-in to the project and the value they are delivering. Trust people, give them all the tools they need to get their job done, pay them what they’re worth, and get the hell out of their way. That’s the “secret” to management.

We need to let developers do their jobs properly, build things properly, and pay down technical debt properly. Otherwise, it smothers us and our products go to hell.

We need to use iterative development

Agile means iterative development, not incremental. Building things breadth-first, to detect and capture customer value in as broad a design space as possible, then simple set-based concurrent engineering to hone down on the delighters that will bowl customers over and maximise throughput.

iterative software development model

We need to change the way we fund work

There is no point getting people to do “scrums” and “sprints” if you’re giving them a twelve-month project from a pre-canned business plan with fixed features and benefits.

The whole point of Agile is frequent discovery and delivery of value. If some budget committee has decided 18 months ago what “value” means for this product, without talking to any customers, or even building a prototype, the exercise is a colossal waste of time and money.

We need to change the way we do accounting

The simple truth is that traditional cost-based accounting methods were fairly outdated and inappropriate in the 1980s, and are now laughably bad. Big successful companies are:

  • made up primarily of people, not physical assets, so traditional balance sheets are largely useless at indicating the long-term value of a company
  • focusing fundamentally on customers, not shareholders (and in doing so, ironically delivering large returns to shareholders)
  • focusing on maximising throughput rather than minimising costs
  • using systems thinking (or ecosystems thinking / whole board thinking), optimising for the whole rather than for a particular product or business unit.

We need to change the way we think about projects

The traditional project mindset worked fine for civil engineering projects in the 1950s, which is where it came from. […] most valuable software work today is about building products, not delivering projects, and products:

  • are (effectively) infinite in duration
  • are built for customers, not stakeholders
  • have no long-term plan or roadmap since they are continuously evolving to customers’ needs
  • are focused on return on investment, not conformance to plan or budget
  • fail or succeed based on customer value created, not conformance to specification.

We need to move from a project to product mindset and fast. I wrote about that here, and Alan Kelly wrote much more about it there.

We need to change the way we run software

It’s not just building it, it’s running it too. No more throwing big piles of buggy code over the wall to poor overworked “Operations teams”.

We need to switch from the horrid half-baked ITIL crap people are doing now to DevOps. Everybody knows it, not enough people are doing it. You build it, you own it, you run it.

Matrix running software

We need to change the way we think about risk

[…] using Agile approaches de-risk work from the beginning, instead of frantically throwing mitigants around at the end. They do this by reducing technical risks through spikes, reducing value risk through early prototypes and releases, reducing quality risk through automated testing, and reducing operational risk through small batch size and continuous delivery.

When people work in an environment based on small business domain focused cross-functional teams, operating on solid microservice architectures, with security and compliance testing as part of their automated test pipelines most governance problems go away.

Conclusion: everyone needs to get on board

It’s quite simple: Agile won’t work if everybody in a company isn’t behind it. It’s about changing the way the whole organisation works: from big slow batches, full of risks and uninformed decisions, to small nimble autonomous and empowered teams. From big clumsy budget cycles and business cases to iterative discretionary funding and continuous delivery.

Leave a Reply

Your email address will not be published. Required fields are marked *