Agile Economics: Scale And The City

Here are the posts in the Agile Economics series:
Gambling IssuesSupply and DemandEarly and OftenDelusions of Grandeur
Scale and the CityScale 3DCost of Change

13wbas[1]What exactly do we want to scale in agile?

As we discussed last time, we want to scale because of the perception that agile “works”, and therefore can relieve the growing pains.

Let’s say it does work at the team level. It eradicates all the communication problems and the team is working at top speed.

Now can we scale?

Not yet. Before I give you permission to self-organize the whole company (are you scared already?) let’s see how we scaled in ye olde days.

Remember supply and demand? Once demand grows we want two things. We want more of the same and quickly. We want to produce more and release early. And we want to cut costs in operations, so manufacturing is cheaper, and therefore we get to keep more money from our profits.

This makes complete sense in an industrial world. If demand for our product grows, we want to produce more (by adding production lines) and cut costs and delays (by replacing hand work with robots). When we talk about the economy of scale, the more we produce, a single item is cheaper to produce.

Oh, one more thing: We know there is demand. We have already found our market.

Scaling in the industrial world means more flow through the pipes. That means more people working on the line, better machines and higher productivity.

Which would work completely the same with software.

Except:

  • Teams interact with each other, unlike production lines. Communication is full of policies, mistakes, egos and delays. More teams mean more people and more delays.
  • There is no “improved” machinery. Intelligence, ideas and execution come at every level and change all the time. Uniformity is gone, predictability is low and tensions are high.
  • Productivity is defined not how much product goes out, but the ability to create valuable products and reduce waste as things change. The output does not determine the outcome, and any optimization is local.
  • The market changes all the time. Mind you, it did this before agile too, but then there was no “cure”.

Agility is the ability of an organization to respond quickly and effectively to the market. Most organizations are not built for that: teams don’t communicate well, policies get in the way of quick response, and productivity is bogged down.

Organizations are by nature anti self-organization. Agile succeeds in teams despite organization structure.

And scaling, prescribed in a colorful poster, we are told, will solve all that. Scaling agility in an entire organization seems like something you’ll read in comic books.

With all the skepticism, there is a way to “scale” agility. Not just in the way you think.

Stay tuned.

 

1 comment on “Agile Economics: Scale And The City”

  1. Brad Appleton Reply

    Interesting article! I think it gets to the fundamental difference between what is traditionally called “Economies of Scale” (which has been frequently applied, with much success, to the problem of mass production of products that exist in the real/physical world). The problem is that software (and hence much of software development) exists in the digital/virtual world where typical “economies of scale” rules are no longer applicable.

    Software development suffers from diseconomies of scale (for reasons you already stated). It more closely aligns with the economic model known as “Economies of Scope” (rather than “economies of scale”). Agile development fundamentally recognizes this shift that requires focusing more on the things needed to rapidly collaborate and acquire+transfer knowledge (and ultimately codify it and then build+integrate it into “working software”). And “scaling” those things isnt the same thing as applying “economies of scale” to an agile process.

Leave a Reply to Brad Appleton Cancel reply

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