Agile vs Waterfall - the wrong question

22 years after the "Manifesto for Agile Software Development," the battle for Agile vs. Waterfall still isn't settled - despite many prominent publications, such as a recent HBR article, trying to "settle the debate."

Unfortunately, this debate can't be settled - because it starts with the wrong question. We will take a look at the question that needs to be asked.

Finding the right question

Most authors start with a question that doesn't bring us any closer to a sensible answer, quite often out of ignorance on what "Agile" is.

What "Waterfall" isn't.

Let's examine some definitions you may find floating around.

"Everything that's wrong"

Well, congratulations: with that definition, even adding too much salt to your breakfast eggs is Waterfall. Fun facts - even "Agile" doesn't prevent things from going wrong, and not even "Waterfall" projects always go wrong (would that mean that Waterfall isn't Waterfall because Waterfa ... argh, paradox!)

A sequential, linear approach from idea to completion.

That's crudely based on Winston Royce's paper from the early 70's - but face it: no company actually works like that, and even Royce wasn't suggesting that. Even "Waterfall," in industry common practice, is a continuous, incremental development approach. Just with very big increments, and extremely slow feedback cycles (it's not unrealistic that it could take 2-5 years between when a requirement is defined until people get the thing they actually need.)

A stage-gated approach to product development.

That definition has two fundamental flaws:
First, you can stage-gate "Agile" approaches as well, and before 2006 (i.e. five years after "Agile") - stage gating wasn't even a thing in most enterprises: You can well do non-Agile projects without stage gates.

You can find another, much more comprehensive article on other things that "Waterfall" is not referenced here.

So we're in a bit of a pickle: We can't even find a non-strawman definition of "Waterfall" that would go beyond the completely fictional definition used in Royce's paper for how to not do things.

What "Agile" isn't.

Let's do the same favor to "Agile" and pull out some of the common misleading beliefs floating around:

Scrum is not Agile

Hard to overemphasize this, but there are two core problems with equating Scrum and "Agile."
First, there's a boatload of terrible Scrum out there that not only doesn't qualify as "Agile," it hardly qualifies as professional.

Second, there are many "Agile" approaches out there, and even though Scrum dialects are the most common, quite a lot of agile companies don't use even Scrum.

Inadequate processes, plans, documents, or contracts

This definition of "Agile" only rings true for illiterate people who can't make sense of the statement "While there is value in these things ..." - Agile approaches make use of these things. Any argument against "Agile" referencing to Agile's inability to structure themselves is either a strawman or ill-informed.

Lack of direction or tracking

Humorously, if that's the definition of "Agile," it's not a stretch to say that most large Enterprises are indeed extremely Agile.

On a more serious note: most professional Agile practitioners will emphasize the importance of clear goals, as well as frequently checking progress on these goals.

We're stuck with the same issue: if we use a strawman definition of "Agile," then everything sensible is a better choice - but none of these definitions hold true to the intent of the Manifesto.
The best definition I can come up with today is based on the very first line of the Manifesto itself: "We are discovering better ways of developing software by doing it and helping others do it." My definition, hence, is "The ability to do the right thing right, at the right time." And with that definition, everyone who proposes anything other than "Agile" - would have to argue why it would be preferable to do the wrong thing, do things wrong, or have poor timing: I find that case extremely hard to make.

Note that this definition of "Agile" says nothing about Frameworks, Methods, Roles or any other form of rules. It doesn't even say anything about values, principles or goals. It's so broad and encompassing that the dividing line is only, "Is that right?"

So - if nobody in their right mind would purposefully do something wrong, why is "Agile" even a thing?
And that leads us to ...

The actual choice

After this introduction, we realize that choice isn't Agile versus Waterfall. It's about answering the question how we deal with things going awry. But: why do things go wrong? Let's take Mark Twain's opinion here:

This provides us a powerful reframing of the entire debate: The "things we know for sure that just ain't so" are - unvalidated assumptions. With this framing, we can rephrase the question to:

How are we dealing with assumptions?

The fundamental choice is: do we proceed based on predetermined assumptions, or do we capture evidence to validate our assumptions? And at which point do we do this?

The framing thus stops being the unfortunate false dichotomy of "Agile vs. Waterfall," it turns into:

Which mechanisms do we employ when reality contradicts our assumptions?

A classical plan-driven approach is built on three core assumptions: we are doing the right thing, we know how to do it right, and we can determine the right timing.

A classical "Agile" approach is built on the core assumption that there is uncertainty: we don't know what the right thing is, we could be doing something wrong, and the world doesn't always follow our timing. The concept is the "VUCA World."

These approaches are both extremes, and in practice, there's always a form of compromise:

• We can start with a hypothesis of what's the right thing, and when it turns out that it isn't, we need to change what we do.
• We can define how we do things, and we have to change that plan when it no longer works.
• We can schedule when we do what, and when we miss that schedule, we need to re-schedule.

Every project manager who learned their ropes will agree that even in a classical, plan-driven approach, this happens all the time. Likewise, every Agilist will concede that we need a product vision, some working agreements, and a bit of forecasting. We can also agree very easily that we need frequent inspection points and to check whether we're on track, and to change direction when that's not true. So - where does the disagreement come from?

Ultimately, we're talking about the probability that an assumption we made is wrong. How likely did we to bet on the wrong horse? How likely are we riding a dead horse? And how likely is the race not going as planned?

Statisticians understand that probabilities aren't 0 or 1, but somewhere in-between. Depending on how likely an event is, we should use practices appropriate to deal with the uncertainty. And depending on how far away an event is, the less likely we can predict it. Hence, the actual question becomes:

How do we deal with uncertainty?

The answer to this question is extremely contextual. We only know that rigid practices without flexibility will be more problematic when we ran into something that we didn't expect - and being so flexible that we can't make any form of prediction isn't sensible, either.

Summary

The question that we should be asking is how much it will cost us to learn that we are wrong? When the answer is tolerable, we are doing okay. Otherwise - we are gambling.

And in some cases, it could be the most wrong and costly thing to not have a detailed long-term plan. Even though that's not considered to be very "Agile."

Little's Law and the Hidden Variable

Did you know there's a hidden variable in Little's Law, and that the traditional equation L = λW - is missing something?
Well, it doesn't tell you something important, and it used to bug me a lot until I could pinpoint it - so let's explore.

What Little's Law says

Quoting Wikipedia: "In mathematical queueing theory, Little's law is a theorem by John Little which states that the long-term average number L of customers in a stationary system is equal to the long-term average effective arrival rate λ multiplied by the average time W that a customer spends in the system."

For example, if we take a restaurant - the average number of guests present (L) is equal to the average arrival rate of guests (λ) multiplied by the average time a guest spends in the restaurant (W).
Let's say, if the average arrival rate is 10 guests per hour (λ = 10 customers/hour) and the average time a guest spends in the restaurant is 30 minutes hour (W = 0.5 hour), then according to Little's Law, the average number of guests in the restaurant (L) would be 5 guests.

Sounds all good - so: what is missing?

When Little's Law doesn't work

A few years ago, I had a hunch that Little's Law was missing something: Imagine that our restaurant has 5 tables and one waiter who can serve 12 guests an hour. Guests take half an hour between getting seated and paying their tab.
Does Little's Restaurant follow the tradtional formula of L = λW, ie., W = L/λ?
Would a reduction of seats lead to guests dining faster?
Would a reduction of maximum dining time generate more guests, or would people dine longer if there were more guests?
Probably not.
Is Little's Law broken?

No. But it's missing something - it doesn't account for system capacity!

Fixing Little's Law?

This modified version of Little's Law accounts for capacity: L = λW / (1 - ρ)

Now, that alone doesn't make sense, so I need to explain this variable ρ:
ρ represents the utilization of the system, calculated as λ / μ, where λ denotes the average arrival rate into the system, μ is the service rate capacity of our system, i.e. the reciprocal of the average service time (1/μ = Ts), where Ts is the average time required to serve a single customer (note the difference between "service time (net time)" and "time spent in the system (gross time)" - it's critical!) The "hidden factor" that Little's Law hid in plain sight was the relationship between the average number of customers (L) and the arrival rate (λ) needs to consider the impact of utilization and system capacity on the system performance! In underutilized systems, an increase in arrival rates has no impact on queues - whereas in overutilized systems, a reduction in system load won't have a visible effect until we get close to the actual capacity limits.

Returning to our restaurant example: Our restaurant's capacity is currently constrained by our amount of tables. As long as we have empty tables, a reduction in customers will not speed up anything. As long as all tables are full, adding more tables to the restaurant won't slow anything down. This view is complete counter-intuitive with the original Little's Law - but it makes sense, even in real life. Oh yeah - at some point, the waiter will be overburdened. At this point, the system capacity is no longer defined by tables, but by the waiter. So it's still all about system capacity.

Some examples

Example values for our Restaurant

μ	λ	W	ρ	L = λW / (1 - ρ)
5	1	0.5	0.2	1
5	2	0.5	0.4	2
5	3	0.5	0.6	4
5	4	0.5	0.8	10 --> bigger than capacity!
10	1	0.5	0.1	1
10	2	0.5	0.2	1
10	6	0.5	0.6	8
10	7	0.5	0.7	12 --> bigger than capacity!
3	1	0.5	0.3	1
3	2	0.5	0.7	3
3	4	0.5	1.3	-6 --> negative!

What's important to note are the three invalid records: When the arrival rates get close to or exceed the system's capacity, the numbers "break down." The real-life effects we would observe here:

• When arrival rates start to approximate the restaurant's capacity, the number of guests present gets bigger than the capacity, which in fact can't be - these invalid numbers indicate that variability could cause a backlog (queue) to form at peak times which can only be serviced when peaks are over.
• Customers arriving to a full restaurant can't get serviced and might leave - i.e., the negative number hints at unserviceable demand, i.e. lost opportunity.

The important observation may sound trivial, but is often ignored in management: only when you have more seats than the arrival rate of guests can you avoid having to send anyone home. And the fewer tables, the more likely someone will have to wait. Which is why a WIP Limit of 1 is just as impractical as not controlling demand influx.

Conclusion

While Little's Law has its merit, and we've been using it for years in order to explain the relationship between throughput, cycle time and Work in Process - we can't use Little's Law to optimize our systems properly if we don't account for System Capacity.
Taking System Capacity into account allows us to predetermine whether increasing or decreasing WIP will have a significant effect - operating significantly below capacity is capacity waste, whereas operating above system capacity causes overload waste.
Thus, the "hidden variable" is more than just important to apply Little's Law - it's crucial!

Further reading

There's an interesting whitepaper by Dr. Little who also highlights the key point of my blog article: as arrival rates approach service rate capacity (as outlined in this blog article,) WIP and processing time skyrocket, "hitting a brick wall" close to the system's capacity as queuing overhead reaches infinity.

SAFe Values - no real value!

Transparency, Built-in Quality, Alignment. Program Execution.

These are the four "SAFe Core Values." But - are they actually, "values?"

What are SAFe Values?

According to the official SAFe website, the SAFe Core Values are:

The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

I would like to focus your attention to the highlighted terms:

1. Fundamental beliefs: In order for "SAFe Values" to make any sense, you must buy into this belief system. If you don't share one or more of the underlying beliefs, the cookie crumbles and the "Value System" of SAFe becomes meaningless. Let's also mention that the idea of "fundamental beliefs" originates from religion - it doesn't coincide well with science.
2. Guiding principles: What is a guiding principle? Let's examine the meaning of a principle: "a fundamental truth or proposition that serves as the foundation for a system of belief or behaviour or for a chain of reasoning." Here, we're pretty close to circular reasoning: SAFe Core Values are fundamental - because they are fundamental. A foundation isn't negotiable, because everything built on it collapses without that foundation. But - are these "fundamental truths" axiomatically true - or are they based on perspective?
3. Dictate behaviour and action - "Dictate" is a much stronger term than, for example, "orient" or even "inform." Based on the fundamentals, you have only one course of action, and it's not open to negotiation or discussion: it's mandatory.

From a linguistic perspective, the SAFe values are beyond scrutiny and would be considered a totalitarian rule: You must believe them, and you must do what they say.

Fundamental beliefs dictating behaviours coincide neither with science - nor agility.

Without getting any further into this matter, let me first clarify that I have never, ever experienced a SAFe fanatic. I have seen my share in the Scrum community, but SAFe practitioners - by and large - tend to be very pragmatic. "Doing what makes sense" is high on the list, and hence, I would give both the idea of "fundamental" beliefs and the idea of "dictating" behaviour a break.

That's just half the matter, though.

The other half is - how these terms tend to be understood in a larger corporation.

Much of an enterprise system is built around the idea that transparency is a one-way street, alignment equals incorporating others' opinions, quality a matter of governance. "Program execution" - well, it requires setting up programmes. With a separation between coordination and execution.

Not-so-fundamental beliefs

A problem of SAFe's core values is that these very underlying beliefs aren't defined from an agile point of view - when a company introduces SAFe, they are taken as "fundamental." Management understands these terms in a certain way, and discussing a "fundamental truth" seems to be a waste of time, because - they're fundamental, and we already understand them. Hence, the crucial discussion, "What do these terms mean?" won't happen. Instead, the terms become a projection of status quo onto an agile organization.

If you start with these four key premises:

1. Transparency: We require a chain of command giving clear orders, and we rely on detailed reports.
2. Alignment: We must ask for the opinions of people not doing a specific piece work, and only do things they agreed to.
3. Built-in Quality: We need some kind of governance telling people what their job is, and how to do it properly.
4. Program Execution: We must set up large programmes which bind a lot of time, money and manpower.

... then congratulations: the core idea of "Agile" is already dead and buried.

Hence, we first need to discuss how we want to understand these terms before we can build an agile organization where these terms even make sense.

What's (a) Value

Unlike beliefs, values aren't "fundamental," "truths," or "principles."

Value, as defined in Oxford dictionary, is:

Value - how much something is worth in money or other goods for which it can be exchanged.

Note again, that there are two critical statements here: worth and exchange.

A value is about the "worth" of something, not a boolean attribute. 

When asking, "What's the value of this car?", you wouldn't expect "Yes" as an answer.

Value only exists when there is a metric and a conversion rate towards another entity, so that people can decide what kinds of trades they would make - and which they would not.

For example, let's assume we measure quality on a scale of 1-10, and you have a quality level of 5. That's merely a measurement: It's not a cross-referenced metric. If you want quality to have value, you would need to relate it to something else, such as "1 quality is worth 3 time."

The statement, "we must have all of built-in quality, alignment, transparency and program execution" would not define "core values." To have an actual value system, we must be able to make trades between quality, alignment, transparency and execution - and we must be able to determine which trade-offs are advantageous, and which aren't.

How much execution are you willing to invest into alignment instead? How much quality would you give for transparency?
These aren't values, unless you can answer those questions.

And for the record - if you'd answer, "None," then you have just discarded the value entirely.

You only have a "value" if you can trade for it.

Considering a SAFe value system

In order to turn "beliefs" into values, we need to be able to make trade-offs based on something. We need to state how much we are willing to give, in order to gain some of what we believe in.

The easiest way to make trade-offs is by investing more or less time or money.

Quality

makes a formidable value, since we can immediately relate it to money: We can determine the cost of poor quality (i.e., the failure to produce high quality) based on projected cost of failure and/or rework. This cost is so staggeringly high that quality has an extremely high value, and the price of reducing it is extremely high. Although the numbers for reducing quality rarely add up, we can do it, and clearly quantify cost, benefit, exchange rate and margins.

Alignment

converts formidably to time - we could do something now, and show the outcomes. Or we could first align, which would mean that we will have no results until alignment is done. It also means that we're not earning money in the meantime. Plus, we're spending effort. Hence, we can assign a financial cost to alignment.

When we can say how many days an improvement / reduction of 1 point on our alignment scale will gain or cost, and how much money we gain / lose during that time, then alignment might become a value.

Transparency

is very hard to turn into a value, because it's extremely hard to define.

What is transparency even - and how would the gain or loss of one point on our transparency scale convert into time or money? We could measure the cost of information inavailability, which in itself is only visible via second-degree indirection - we must peek at the delays incurred by waiting for information to become available, and at the cost of that time. We could also measure the cost of evitable, wrong decisions that were made because people made choices in the absence of existing information. We then also need to reverse the calculation, computing the cost and time required for producing information not required for decision-making ("information waste").

Companies capturing this kind of data are so rare that the measurement of transparency remains elusive.

 

Execution

simply doesn't make sense as a "value." How much time or money is one unit of "not doing anything" worth? How many would we want? Is there ever even a potentially valid scenario where having a plan, and not acting upon it, has a positive value attached? If so - we should immediately ditch that plan! 

And that's not even digging into the question whethere there's value in a "program," that is, a large-scale initiative. Skunkworks has already shown two generations ago that programmes are often more of a problem than a solution.

SAFe Core Values - a wishlist for Santa!

When we're talking about "SAFe Core Values", we're not talking about values at all, since we're not even discussing potential trade-offs.

Quality is the only "value" of SAFe that managers would actually consider trading off, despite being so ridiculously expensive that this isn't economical: The best quality has the lowest cost - "less costs more and brings less." It's absolutely something an economical thinker would want to maximize.

Alignment, as commonly understood, comes with a negative net benefit - "more costs more and brings less." So, it's not something of value. Why would we want it, besides clinging to a belief that it's somehow important?

Transparency is too elusive to be considered a value: Everyone wants it, but nobody can really say what, or how much, we'd want to trade for it.

Program Execution doesn't make sense as a value. It's boolean: If we want to do something, just do it. If we don't want to do it - why is it relevant?

Hence, SAFe's "core values" are nothing more than a wishlist for Santa - something that almost every manager in the world will say they want, and nothing they'd be willing to pay a price for. 

Anything for which you're unwilling to pay a price, has no value. It therefore can't be considered a value.

SAFe has only one real value: built-in quality. And that's the first ones most organizations kick out of the window.

If you want SAFe "Values", you'll need to do a lot of groundwork and figure out what it is that you actually want: You're not done with simply accepting them.

The economy of incentives

People working in bigger companies often do things which don't really seem to make sense when looking at the big picture. And yet, they're often pretty reasonable in their choices. They are intuitively following basic psychological and economical principles. Let's explore.

The economy of needs, wants and incentives

Let's start out at the detail level of the individual. Each person has needs:

The need pyramid

Maslow's hierarchies of Needs, sometimes also called "Maslow's pyramid" is built on the theory that every human being has needs, and these needs follow a hierarchical order. This picture is already a simplification, more comprehensive models are abundant on the Internet. 

While each person has the same types of needs and the pyramid is the same, the level at which these needs are considered "satisfied" widely differ. 

One person might feel basically satisfied with a bowl of rice and a few cups of water, whereas another person requires a more special diet to  sustain. These are the basic needs, which must be met to ensure survival. People whose basic needs aren't met will not have a mind to think about other things, their primary concern will always be meeting these needs.

Once people are satisfied at the basis, they care for psychological needs - family, social ties, being accepted and valued.

With such a firm foundation starts the restless search for meaning in life - developing one's personality,  being creative, pursuing a cause. At this level, people look for transcendency.

Dan Pink mentions this in his book, "Drive" - without fully realizing that it's not just that the money must be off the table, but all basic and psychological needs. People who feel threatened for their physiological well-being or social status aren't looking for transcendence, so in order to set up an organization where people go to look for a higher purpose, there's a lot of groundwork to be done in taking care of people first.

From "Need" to "Want"

Unmet needs cause dissatisfaction with the status quo. This is also true for the future, because people think ahead.

We build our needs pyramid from the bottom, and whenever a lower-levelled needs turns to an unmet status, everything on top of that need gets out of focus. A starving person doesn't care for appreciation (many artists can tell that story.) A bullied person won't feel the office aesthetics. And so on. So, when a person has an unmet need, they want something, and action is required to satisfy the need (although it could be a different actor to serve the person in need.)

There are a lot of intermediary Wants - for example, money can be used to meet all kinds of need. When a person is hungry, they want money to buy food. Or drink. Or to pay the rent. Once basic needs are satisfied, they might invest that money to buy a token of wealth that meets their need for social recognition. And so on.

Other intermediary Wants, such as a promotion, could be more complex: Is it about the job title for prestige, is it about the presumed job security, about the additional pay, is it to rise the ranks to improve status? Maybe all - maybe only some. 

Or maybe the idea that the Want satisfies the need is an illusion?

The key takeaway here is - if there's a need, there is a want. Ignoring the underlying need will render attempts to satisfying a Want ineffective.

Incentives

Incentives don't directly affect needs. They work because they trigger (both positive and negative) wants: things the individual wants, in order to meet needs - and things the individual wants to avoid, in order to not have needs unmet.

An incentive always stimulates at least one Want. 

Positive incentives

Positive incentives give people the ability to satisfy their needs if they conduct a certain action. The most common form of positive incentive is, "Do your job, get your paycheck." Even a simple "thumbs up" from a coworker can be an incentive to try and go the extra mile. 

The strength of an incentive depends much less on the nominal amount of incentivization - much rather, it depends on the level of unmet need. For example, you won't entice Donald Trump with a Thumbs Up, but the new team member who's not certain of their position in the team yet may be willing to go great lengths to finally get the lead developer to nod in agreement of something.

Negative incentives

Just like positive incentives, we can find ourselves subject to negative incentives.  For example, the negative incentive "skip dinner"  attached to overtime plays on our Want to not be hungry.

In society, we use negative incentives to deter certain behaviours, such as fines (which affect people differently, depending on their wealth.) 

Explicitly phrasing negative incentives helps people discover which courses of actions are desirable and which are undesirable.

Managers quickly forget that there are almost always some negative incentives attached to their words: Even asking for a trivial thing might leads to the person feeling their status in front of their peers is diminished - a negative incentive, which people try to avoid.

The incentive economy

An economy is defined by wealth - in this case, we define "wealth" as satisfied needs.

In the case of incentives, we're dealing with promises of future wealth, hence, a value proposition to the recipient of the incentive.

Passive incentives

"What could be a passive incentive?" - well, that's an incentive created by doing nothing. Taking an extreme example, when a police officer continues munching donuts while a robber demands cash from the store owner, that's an incentive for the robber to commit further crimes. We see much less extreme examples in everyday's business world as managers fail to acknowledge the successes and contribution of their teams, incentivizing individuals to either cut down on performance (if stress is affecting their basic needs) - or to start hunting for a better job.

The nefarious thing about passive incentives is that you literally don't need to do anything to trigger them.

Ineffective incentives

The next type of incentives we're looking at are ineffective incentives. A positive incentive which doesn't address a real Want is entirely ineffective - as are negative incentives which don't touch a relevant need. This is also the reason why a pay raise for a person who's already fully able to meet their basic and psychological needs is pretty ineffective, as Dan Pink in his work, "Drive" figured out.

The same is true for "fun activity at work" while people are worried about not being able to afford the rent: it affects a higher-levelled need while there are lower-levelled Wants.

We can try to manipulate people by suggesting that they do have a certain Want, a typical marketing strategy. Here we can quote Lincoln, "you can fool some of the people all of the time, and all of the people some of the time, but you can't fool all of the people all of the time." Eventually, people will realize that an incentive doesn't affect their needs, and they will ignore it. That is especially true for  things often called "non-monetary incentives."

Likewise, when a person finds alternative ways of satisfying their Needs, the Want disappears, and the incentive fizzles. For example, new joiners will stop trying to achieve the recognition of their boss when they feel that the recognition of their peers means a lot more. 

Hence, long-term incentives that have alternatives tend to be ineffective. 

Perverse incentives

The final category of incentives are perverse incentives - these are different from the other categories.

When we try to incentivize an action, we usually try to do that to get a benefit from what they do. The term, "perverse incentive" comes into play when people have the Want, but the intended incentivized action isn't actually what people to in order to meet their need, and so they go to do undesirable things. "Cobra Farming" is a notorious example of a perverse incentive.

The problem with perverse incentives is that they work extremely well - just not in the way that the incentive-giver intended. 

And there's another problem: Perverse incentives are extremely common in complex organizations where the relationship between cause and effect isn't clear.

Setting incentives without connecting to the recipient's reality often leads to perverted incentives.  

Top managers coming up with broad-brushed incentivization schemes for people at shop floor level often realize this only when it's already too late.

Summary

Bringing it all together - we have to understand the real needs and how they can be met. We must learn to go beyond merely talking about our Wants.

From there, we must learn how to take care of each other's needs in effective ways.

That allows us to become explicit on the incentives that let us build "Win-Win" scenarios.

The Agile Tragedy of Commons

There's a socioeconomical dilemma called, "Tragedy of the Commons" which effectively means, "In unregulated systems, local optimization may become so extreme that the system becomes unsustainable."
And here's why you need to understand it in order to understand "agility at scale."

Before we get started, though, let me explain the dilemma:

The Tragedy of Commons

Imagine there's a huge, pristine green pasture. The lord of the land has decreed that everyone is free to use this pasture for shepherding their flock.

The first shepherd who arrives finds a vast green pasture, and the flock is happy to graze on the fields.

Soon afterwards, another shepherd arrives, and their sheep graze happily on the lush pasture as well. Both shepherds are happy, as their sheep have ample food to eat.

In the excellent conditions, the flocks multiply.

As the flocks grow, there is no longer an overabundance - the sheep of the two shepherds begin competing for food. The first shepherd's sheep had more time to multiply, and the second shepherd's sheep lack the required conditions to multiply freely.

Both flocks compete over increasingly scarce food: the sheep lack nutrition and are threatened from starvation. The first shepherd feels that the second shepherd's presence has caused this threat to their flock. The second shepherd considers the first to be using their unfair advantage of having a bigger flock to drive them off the pasture. Quarrels arise.

The feudal lord settles the dispute by dividing the once lush green pasture into an allotted segment for each shepherd, based on the size of their flock. Both shepherds now have access to less land than they could access before - but each now has full control over their flock.

Should the lord have settled the dispute in this way? Should the lord have found another solution? Take some time to think. What would have happened - had the lord not intervened?

Tragedy of Agile Commons

There are many, and massive, applications to the Tragedy of Commons in the realm of software systems - moreso in scaled environments. In the land of Agile, they're much more visible than in the land of Waterfalls, where the lots are already divided before they exist: Agile teams incrementally and empirically discover their next best move based on where they are today - perfect preconditions for the Tragedy of Commons.

Common Code

Teams who haven't learnt discipline in code will find it highly irritating to see one developer interfering with another developer's code: "my" coding style is always better than "yours."

Quickly, quality problems begin arising on the Common Codebase: quarrels over style, functionality placement, inconsistencies and many others.

As more and more developers enter the scene, the tendency for code silos built around personal preference, coding style, technologies, or even domains increases.

Whereas one team can often be left to freely roam the green pastures of service implementation, the field quickly turns into a brown quagmire when multiple teams all play their preferences, until the code base becomes entirely unworkable.

Once teams build fences around their codebase, Collective Code Ownership becomes a thing of the past, and Component Teams find themselves entertaining a dreadful nightmare of coordination meetings.

Better approaches could be:

• code conventions
• linting rules
• cross-team Pairing sessions
• Code dojos
• Continuous Integration / Continous Delivery

- but these things are all topics large organizations struggle with after the code has been divided into silos.

Common Innovation

A green field project is often a great way to introduce new, more powerful technologies that allow teams to do less with more.

As the development organization matures, and standards begin to shape the landscape, new ideas becomes exotic and marginal, struggling to overcome inertia.

Imagine - just for example - introducing agent-based logic into an architecture driven by RPC's and SOAP requests: There will be few takers for such an innovation.

The Tragedy of Common Innovation is that new ideas have to find a really small niche when the field is already taken by old ideas. Many good ideas go extinct before they can catch a hold.

With a constant decline of innovative ideas, organizations eventually find themselves investing massive efforts into servicing outdates ways of working and technologies, incapacitating their ability to deliver high value to the customer in the same ways others do.

Better approaches might be:

• innovation allotments
• hackathons
• innovation sessions
• innovation champions
• cross-team collaboration on innovation
• intrapreneurship

Common Meetings

Have you ever been in a 2-hour meeting with 40 people? Did you ever pay attention to how many people actually speak? Hint: it's most likely not an even distribution.

Small organizations find their meetings very effective, but as more and more people appear on the scene, meeting effectiveness quickly declines. And there's a reason.

In an effective 3-people, 1-hour meeting, every person gets to speak roughly 20 minutes. That's a lot of time to voice ideas, offer feedback and draw conclusions. That's a 33% activity ratio. And everyone has pretty much the same understanding afterwards.

When we constrast this with a 30-people, 2-hour meeting: Simply by dividing clock time, we see that every person gets to speak an average of 4 minutes, while being forced to listen for an average of 116 minutes: The ratio of ideas contributed versus passivity is staggering for each individual - the activity ratio has dropped to a mere 3%! In such a scenario, the tragedy of common meetings becomes that some of the more experienced people take the stage, and everyone else becomes decoration.

Solution approaches might be:

• focus sessions
• using a need-to-know principle
• Law of Two Feet
• breakout sessions
• topic ownership

Specialisation also removes the need for everyone to participate in all discussions.

The tradeoff is mainly between not everyone getting firsthand information and people suffering through hours of only marginally relevant meetings. To any solution, there's a downside.

Common Work

A single developer can work on any code at any time, and there will be no unpredicted side effects like merge conflicts caused by others' work. Small teams will usually learn quickly how to coordinate so that they minimize mutual interference.

Without good engineering practice, delivering a larger, integrated piece of software means lots of simultaneous changes in many places. Teams will either get into a Riverdance of constantly stepping on each other's toes, or they will require so much coordination that things get really messy. Of course, the "solution," is - once again - code silos and dependency hell: productivity tanks as risks and delays rise skywards.

Every developer joining an organization that hasn't managed to deal with the Tragedy of Common Work adequately, will make every developer's productivity decline - up to a point where the net productivity gain of hiring additional developers may be negative, i.e. with each new hire, the organization gets less productive overall!

Potential solutions could be:

• visual dependency management
• domain separation
• decoupling
• joint roadmap planning
• cyclical synchronisation points
• communication by code

Now what?

These are just four examples of how the Tragedy of Commons matters a lot in a Scaled Agile setting, and there are a vast number of potential commons.

Regardless of whether an Enterprise is new to agile ways of working or have been doing so for a while: you need to establish overarching rules that mitigate the conflicts, lest you run afoul of the Tragedy of Commons.

The "Tragedy of Commons" is entirely evitable in a holistic system where every participant sees themselves as an integral part of the whole. The solution is coexistence and collaborative conflict resolution rather than competition.

Ground rules address unregulated, harmful growth, a lack of discipline, and myopic actions, but each rule comes with a drawback: it reduces flexibility. While Team Autonomy needs boundaries where these are for the Greater Good, it's important to set these boundaries wisely, and revisiting these where they aren't useful. That can't be done by only one group - in a common system, it has to involve all those whom it concerns.

Which boundaries will you set to prevent your organization from suffering the Tragedy of the Commons, and what is their cost?

The "Planning Tetris" Antipattern

 "We need to utilize all of our Story Points" - that's a common dysfunction in many Scrum teams, and especially in SAFe's Agile Release Trains where teams operate on a Planning horizon of 3-5 Sprints. It results in an antipattern often called "Planning Tetris." It's extremely harmful, and here's why.

Although the above feature plan appears to be perfectly optimized, reality often looks different: all items generate value later than they potentially could - at a higher cost, in longer time and with lower efficiency!

Accumulating Work in Process

Planning Tetris often leads to people starting work on multiple topics in one Sprint, and then finishing it in a later Sprint. It is resource-efficient (i.e. maximizing the utilization of available time), not throughput-efficient (i.e., maximizing the rate at which value is generated.)

That leads to increased Work in Process, which is a problem for multiple reasons:

Value Denial

Just like in the sample diagram above, "Feature 1" and "Feature 2" could each be finished in a single Sprint. And still, Feature 1 doesn't provide any value in Sprint 1, and Feature 2 has no value in Sprint 2. So, we lose 1 Sprint of marketability on Feature 1 (our highest priority) - and on Feature 2 as well:

A perfect example how utilizing the team makes the value come later!

Loss of money

Imagine now that every feature costs less than it's worth (which it should, otherwise it wouldn't be worth developing) - and you see that the "saved" efficiency of having worked on features 3 and 4 before finishing feature 1 costs the company more money than the added benefit .

Efficiency loss

You may argue, "different people are working on the features, so there's no multitasking."

Yes - and no. What is happening?

Sprint Planning for Sprint 1 has to discuss 3 features: 1,3 and 4. This means that the whole team is discussing three different topics, (none of which will be delivered in that Sprint.) The same happens in Dailies and Review. And, potentially at a source code level as well. The feature interference may also bloat up the complexity of technical configuration, deployment processes and the like.

The team becomes slower, hence less efficient.

Adding needless risk

In statistics, there's a phenomenon called "the high probability of low probability events." Let me explain briefly:  There's an infinite amount of almost infinitely-unlikely events, but unfortunately, high infinity divided by low infinitiy is still a number close to one: Something will happen. You just don't know what, and when, so you can't prepare or mitigate. Since you don't know which aspect of your plan will be affected when a risk hits, you'll always be caught by surprise.

How is that a bigger problem in Planning Tetris than in sequentialized delivery?

Massive ripple effect

When you're working on one topic, and an event hits that affects your entire team, you have one problem to communicate. When the same happens as you're working on multiple topics, all of them are impacted, and you're generating a much stronger ripple effect.

Complex mitigation

As multiple topics are in process, you suddenly find yourself mitigating multiple topics. And that means multiplicative mitigation effort - less time to work, and at the same time a higher risk that not all mitigations are successful. You end up with a higher probability of not being able to get back on track!

Chaotic consequences

Both the ripple effect into the organization and the mitigating actions could lead to unpredicted consequences which are even harder to predict than the triggering event. In many cases, the only feasible solution is to surrender and mark all started topics as delayed, and try to clean up the shards from there.

Prepare to Fail

There's Parkinson's Law - "work always extends to fill the amount of time available." That's often used as an argument to start another topic, because it stops gold-plating and keeps people focused.

But there's also the (F)Law of Averages: "Plans based on averages fail half the time."

The latter makes planning tetris a suicidal approach from a business perspective: it starts a vicious circle.

Predictable failure

Because there's no slack built into planned tetris, the mid-term plan will automatically fail as soon as a single feature turns out more complex than planned. The more features are part of our tetris stack, the more likely at least one of them will fail. And the team will usually get blamed for it. Because of that, we end up with

Conservative estimates

Teams must allocate the slack buffers into their feature estimates to reduce the probability of failure. When a Tetris plan spans multiple Sprints, some feature content may not be "Ready" for implementation during the Sprint when slack would be available - so we end up with Parkinson's Law, the buffered estimates don't reduce failure probabilities. 

Declining throughput

At this point, Parkinson's Law tag-teams with the Flaw of Averages to KO the team: Regardless of how conservative the estimates, the team will still end up failing half the time. The consequence is that business throughput continues to decline (there's an interesting bottom: when a Sprint only contains one feature!) 

Strangulating the team

Let's take a look at the psychological impact of Planning Tetris now as well:

No space for Creativity

I have never seen an organization where Product Management was happy that developers would add "creative spaces" into a Tetris Plan. It's all about churning out feature, after feature, after feature, without a pause, without a break. When one feature is done, another is already in progress. There is no room to be creative.

No space for Growth

The only relevant business outcome in Tetris Plans is usually business value delivered. It ignores that developers are the human capital of the organization, and growing them is growing the organization's ability to deliver value. Especially in the rapidly changing tech industry, not growing equals falling back until eventually, the team is no longer competitive.

No space for Improvement

I often advise that developers should take some time to look at "Done" work to reflect how it could have been done better, and turning that better way into action. With Planning Tetris, that opportunity doesn't exist - another feature is waiting, and improving something that exists is always less important than delivering the next big thing. That often ends in terrible products which are no joy to deal with - for developers and customers alike!

Now ... what then?

The point that Planning Tetris is a terrible idea should be blatantly obvious.

"Now what's the better way then?" - you may ask.

It sounds incredibly simplistic, because it is actually that simple.

1.  Reduce the amount of features the team is working on in parallel to an absolute minimum. This minimizes blast radius.
2.  Instead of having people parallelize multiple topics, let "inefficient", "not-skilled" people take easier parts of the work to step up their game. That reduces the impact of low-probability events and gives everyone air to breathe.
3.  Put slack into the Sprints. The gained resilience can absorb impact. It also reduces the need for buffered estimates, countering Parkinson's Law and the Flaw of Averages. It also gives people air to breathe.
4.  Agree on Pull-Forward. When the team feels idle, they can always pull future topics into unused idle time. Nobody complains when a topic is finished ahead of time, everyone complains when something turns late. Pull Forward has no ripple effects or chaotic consequences.

Ok, too many words, so TL;DR:

1. Sequentialize.
2. Slack.
3. Pull.

All problems mentioned in this article = solved.

Entrepreneurial Value for in-house development

"We can't measure the monetary value of a Feature". A common complaint, and oftentimes mere ignorance. It's economically disastrous for an organization that spends money on software development!

Here are a few simple, effective ways of making the value of development transparent even when developing complex in-house systems:

Core goals

Before we start, we need to understand that there are fundamentally two different reasons for developing software. While occasionally, these goals can be combined, they are usually distinct, and one of them takes priority.

Revenue increase

Some components allow the company to generate more revenue - acquire new customers, sell additional goods, etc. For those components, measuring feature value is very straightforward: The value is the difference in revenue that can be attributed to the implementation of a feature.

In these cases, the value of a feature can be found on the "Assets" section of the balance sheet - the difference between old and new assets.

Expense reduction

For established processes, most of the work is aimed at increasing efficiency through performance optimization - saving time or resources (e,g., packaging / fuel etc.) to reduce expenses.

In these cases, the value of a feature can be found on the "Liabilities" section of the balance sheet - the difference between old and new liability.

Equity generation?

Argubably, there may be features that turn out to neither generate revenue nor cut down on expenses.

Many people argue that "you got what you got", and proceed to treat such features as assets - claiming that they are becoming shareholder equity that doesn't show up as cash flow.
I, myself, would argue that this is not the case.

From a technical perspective, such features need to be candidates for removal - in software, every feature has code, and every line of code increases the product's complexity, and complexity correlates to the amount of work required to deliver future value -- hence, such features, though seemingly innocent, are technical liabilities!

Determine feature value

After the above is established, we will not discriminate anymore whether a feature's value is determined by an increase in revenue or reduced expenses. Instead of providing specific techniques or methods, this section focuses on thinking patterns that help in determining the value of feature.
These patterns can be selected or combined based on circumstance.

Value Stream thinking

Understand the operational value stream you are contributing to, and the place you hold in that value stream. Your contribution to that value stream is the leverage you have for development.
For example, when your value stream produces a revenue of $10000 a day, and after the implementation of the feature, it's still $10000 a day ... how much did the feature add? Maybe it reduced operating expenses. If, however, they are still the same, the feature did zilch.

Theory of Constraints is a great method of figuring out whether it's even theoretically possible for your feature to add value: if you're not working on the value stream's current or next constraint, chances are slim that you will add value to the organization!

Make of Buy thinking

There's an economics proverb, "If it's known, and you can earn money with it, someone is already doing it." In many cases, there's already a vendor solution that does the same thing you would be developing, and that vendor has a price tag attached to their solution.

While you still can't know if that's going to be the actual value of your feature, the NPV is capped at whatever this vendor is asking. So, for example, if you could buy a cloud solution that solves your problem at $199 a month, we ignore discount rates and cash flow, calculating NPV for a 5-year period, we'd end up with the feature being worth no more than $12k. So unless you can deliver it cheaper, you may not want to build it.

Service thinking

If you remember the beginning of the Internet age, AOL was a service born when companies realized that they had capacities available that others would pay for. Internet giants like Google and Amazon have since successfully replicated the model of selling a solution to their own problem to others as well. You already paid for it - so every cent you make with a sale is net profit! What is stopping you from capitalizing on the idea? If you're doing it right, there's even a chance you can make more money off selling the feature to others than the value it has within your own organization! More than one software company was borne out of scratching one's own itch.

Even if you're producing something "in-house", always ask the question, "Who else has this problem, and how much are they willing to pay to get it solved?" - if the answer boils down to, "Nobody" or "Nothing", then chances are that you're solving the wrong problem.

Let's talk about Demand

While "Agile Development" focuses exclusively on supply mechanics, an understanding of demand mechanics is essential to managing sustainable product development - agile or non-agile, hence I want to lay a foundation of the effect demand has on a development organization.


Synopsis
A basic understanding of the economic dynamics of Supply and Demand is essential to succeed with product development. As development capacity is a limited resource, free market dynamics do not apply to product development. Without understanding and managing demand, agile product development sets itself up for failure, yet few (if any) agilists understand "demand". This article provides a basic explanation of the impact demand has on your development organization - and how you can use this knowledge to increase your odds of succeeding.

Demand in economics

There are huge misunderstandings in the agile community as to what is "demand" - down to the point where people claim that demand management isn't anything other than working the Product Backlog. Since we have ITIL, a lot of IT people seem to confuse "Demand Management" with "Requirements Management" - and conflate "demand" with "requirement", or, using agile lingo, "user stories".
Let's get back to basics for a bit.

The most fundamental concept of Keynesian economics is Supply and Demand. In a free, unrestricted market, this is the gist of Supply and Demand:

Where supply and demand meet, there's an equilibrium

"Demand" is simply how much of a given good or service people request - and "Supply" is how much of that will be available. There is also "aggregate supply" and "aggregate demand" for the whole range of good or services within an economy.

This model leads to some very intuitive statements:

• As price decreases, demand increases. People demand more at a low price.
• As price increases, supply increases. People are more willing to offer things at a high price.
• At some point, there's a market equilibrium: supply meets demand.

To make this article simpler, from now on, I will infer "good" to mean "any kind of service provided by IT development", "quantity" to mean to "the amount of this good [created or requested]" and "price" as "cost of that good". I will ignore the definition of "price" as in whether that cost is opportunity cost, total cost of ownership or whatever - that too, might be a topic in and of itself. For now, just think of the most comprehensive definition of "price" you can imagine.

While macroeconomic concepts can not be applied to a division of an organization without further examination of the existing conditions, this would go significantly beyond a short blog article. To keep matters simple: The development organization (typically IT) offers certain services ("supplier") to the rest of the business and to customers ("consumers"). From there, we get into the nitty-gritty that may be worth another article.

In this context, "demand" is simply everything that consumers want, which the supplier could provide. There is no constraint that "demand" needs to be known or voiced. It can only be itemized once it's known and articulated. Therefore, demand starts long before a specific item appears in a Product Backlog.

Scarcity and Supply Limits

When a resource (in this case: time) in the production of a good is limited, this generates "Scarcity": the quantity of the good is capped due to the supply limt of the resource.

Beyond the supply limit, price is irrelevant. The demand will not be met.

On the right side of the supply limit, price and demand are irrelevant: There is no way to meet the demand - it's economically impossible. Just imagine that you wanted two suns on the sky - there is only one, so it's simply irrelevant how much you would pay to have a second - there won't be another.

We see the same thing happening when a development team (or: the development organization) has a fairly fixed size. You can slice it however you want, a day still has only 24 hours and 10 people are still only 10 people, so there is some kind of limit in place.

Let us simplify our model once again and ignore the possibility of hiring additional people, because we would still need to observe two effects here described quite appropriately in "The Mythical Man-Month" and "The Phoenix Project", that there's no guarantee that additional headcount will increase the supply limit. Even if we could increase headcount and developers were fungible, there would be still diminishing returns and scarcity of available developers, another topic that we can wonderfully descope for another article.

Increasing demand

As our business grows more successful over time. the demand for goods from the development organization increases. Whereas in the initial phase of our business, developers were experimenting a lot and had a fair amount of time to figure out the best solution, increasing demand brings development closer to its supply limit.

While a low demand can be met at a low cost, there is no way to meet the high demand beyond the supply limit that many development organizations experience.

As we get closer to this supply limit. businesses get the impression that their development becomes slower, less flexible and unproportionally costly. Close to the supply limit, the marginal price increases dramatically with ever diminishing returns on invest.

As demand increases, cost increases significantly faster than quantity

The average unit price of getting a new feature also goes up - not because development cost went up, but because of increasing competition over a limited good. Notice that this is demand competition, not supply competition. Demand competition means that people will use their influence and available means to get what they want, so the people with less influence or money will not be supplied.
Or, to translate the impact of demand competition into the world of product development: At some point, the development organization will no longer be able to serve everyone.

If now we translate this into the world of software again: as businesses become more successful, their demand for IT continuously increases. When a specific request arrives in the development organization, it's either on a point in the demand curve where supply can meet demand - or it isn't. If it is not, then it will not be in the future, because demand is moving up ...

A very simple rule of thumb in a limited supply system is: Unless demand decreases at some point, if you can't get it now, you never will.

... unless...
... demand decreases!

Demand Inflation

Which it won't, because everyone intuitively figures out this rule of thumb. As a consequence, we see a followup phenomenon: When stakeholders start to realize that their requests aren't being met, they try to get the development organization to commit to delivering as many goods as eary as possible, because later, it will be even harder to get this commitment!

This is the point where we enter the vicious circle of starting as many initiatives as possible, irrespective of whether there is enough capacity to complete these initiatives. The capacity problem is delegated to the product organization once there's commitment to deliver upon a certain request.

This vicious circle can't be broken on the supply side

The mechanics we see at work here are exactly the same mechanics that you saw during the World Banking Crisis: As soon as a bank declares that they can't pay back everyone's deposits, everyone will try to be the first to secure as much of their deposit as possible.
The announcement that "we can't serve everyone" is enough to start a spiral so powerful that it can destroy corporations and topple governments - what makes you think that your Product Owner will fare better?

Demand Management

A missing piece in the typical agile approach is that typical IT people understand little to nothing about supply and demand - and even less about demand managment.

Demand management isn't the exercise of itemizing and keeping an inventory "user stories" or other backlog items, and determining which items get implemented next (and which won't get implemented at all).

At the very minute a stakeholder receives the idea that maybe the development organization can't do it all, you start a "bank run", inviting all stakeholders to flood you with as many requests as possible, worsening your problem rather than fixing it!

Demand Shaping

A terrible misunderstanding propagated by many agile coaches and trainers is the idea that it's enough to manage the supply side of product development and have a mechanism to determine the priority and content of the product backlog, then being vocal about saying, "No" to requests for goods that have no chance of being implemented.
Simply managing the product backlog is too late in the process and a local optimization.

Let me give you an example of what "demand shaping" means:

The Diner Metaphor

You go into a Mexican diner to have lunch. The diner has already shaped your demand long before you looked at the menu.  You would be irrational to request breakfast for lunch, and you would be even more irrational to request a sushi platter there.
The restaurant probably won't have to tell anyone that both of these requests won't be served, because nobody expects to get served these dishes to begin with. Nobody would feel offended when the waiter tells a person with a sushi craving that there's an excellent sushi bar down the road.

If the diner is high class, they will not serve you a "product backlog", or a list of 150 different dishes that you can choose from. Their menu will contain maybe four to ten items, all of which the restaurant manager knows to be fast and profitable to produce at a high quality.

The next step of demand shaping happens when you approach the door and see this giant sign "Lunch Menu $6.99"  with some really tasty looking food imagery. At this point, most customers will already have lost their interest in the menu and place their order. The placement, the imagery and the price tag are enough to reduce the demand for other items by a good 80% - speaking from a Pareto Principle, the sign plus their brand is enough to give the diner what can be called "demand control".

At the same time, the manager will constantly track which dishes get ordered and if there are new trends on the market, without any direct intention to provide any of these. Even if the customers are aware of this, they have no way to influence the manager's decisions as to what the future menu will look like beyond what they choose to order. Next week's special offer and menu will be optimized to maximize sales, while minimizing effort, and if the manager makes the right predictions, customers will be happy even though they were never asked for their opinion.
This is called "demand monitoring" and "demand prediction".

The failure of IT Development

Whereas the Mexican Diner in our example made it clear that they're not a Sushi Bar, a typical company's IT department wants to have full and exclusive control of everything pertaining to Information Technology.
All of this is operating under the assumption that the the demand on a development organization can be met by the available supply.
Once demand is beyond supply, which is a natural consequence of having a successful product with unshaped demand, the organization must choose which demand it will serve and which it doesn't.

There are multiple strategies for dealing with over-demand:

1. Start the "Demand Inflation" spiral and get into a neverending battle about priorities.
2. Encourage a "Bank Run", which will destroy the credibility of your organization.
3. Start "Demand Shaping" to reduce over-demand.
4. Specialize. Stop claiming to do everything. Let others do what they can.

Smart organizations, irrespective of their development approach, will pick option 3 to reduce demand as far as possible, then pick option 4 once that is no longer an option.

Agile Frameworks like Scrum and SAFe will lead unsuspecting Product Owners/Managers into the trap of picking options 1 and 2, which may eventually lead to a failure of the entire organization.

The meta-failure of "Agile"

Managers who look towards "Agile" as ways of improving Time-to-Market and Quality easily get swayed by the claims that "Agile" will improve these metrics, while also increasing employee engagement and customer satisfaction. Hence, they transition their organizations towards agile ways of working. Product Managers get re-eductated to follow "Agile Product Management Practice", which focuses exclusively on short-term supply management and entirely ignores long-term demand management.

As a sweeping statement, agilists with an IT background are terrible at understanding market dynamics and the nature of demand. They only understand the supply side, as that's what they're typically working on. Hence, they can't help on the demand side. Letting a myopic supply-centric approach become your product strategy will be disastrous.

If your "Agile Transformation" has no demand management strategy, or if you think that "let's put everything into a backlog, then pull the most valuable items first" is a demand management strategy, you are going to shipwreck! The bank run is inevitable.

Conclusion

"Agile frameworks have little to nothing worthwhile to offer in terms of demand management. They focus exclusively on managing the supply."

Understanding and managing demand is an important part of managing a sustainable development organization. Agile frameworks have little to nothing worthwhile to offer in terms of demand management. They focus exclusively on managing the supply. Claims that demand control is not required in an "Agile" environment are myopic, made from ignorance - and can lead to catastrophic outcomes in the long term.

Organizational managers and product people alike need to understand demand management principles and practices to steer a product towards sustainable success.  An understanding of the "market" created and engaged by the development organization is essential to determine what the best next steps are.
In some cases, backtracking and demand reduction may be required before one can even begin working with a Product Backlog. Failure to understand this may result in the entire "Agile Tranformation" becoming a no-win scenario for all people involved.

To Explore

This article relies on a lot of shortcuts and makes a number of strong assumptions.
A number of additional items still need to be explored, and I invite the reader to do some of this exploration on their on until I have time to provide additional material.
These items are:

• The applicability of Keynesian Economics to [IT] product development
• The definition of a "good" in the context of [IT] product development
• The definition of "price" / "cost" in the context of [IT] product development
• The Supplier / Consumer Relationship in the context of [IT] product development
• The interaction between product development and non-developmental IT
• Why "Development Manpower" is not a fungible good
• Why a "Supply Limit" exists
• The causes of demand increase in product development
• The causes for starting a bank run on product development
• The effects of a bank run on product development
• Demand shaping in software development
• The effect of demand shaping on development performance
• The effect of having "cross-functional teams" on the complexity of the work
• The trade-offs, benefits and disadvantages of specialization