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:
- Start the "Demand Inflation" spiral and get into a neverending battle about priorities.
- Encourage a "Bank Run", which will destroy the credibility of your organization.
- Start "Demand Shaping" to reduce over-demand.
- Specialize. Stop claiming to do everything. Let others do what they can.
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
No comments:
Post a Comment