When an organization decides to adopt the Agile values and principles, it can choose to adopt a framework providing roles, rules and events to achieve that. Practice shows however, that the mere application of these frameworks usually isn’t enough.
To actually reap the benefits, an Agile framework adoption should result in an organization that constantly knows about its current reality relative to the goals that organization has set itself. If it detects a gap between its goal and current reality, the organization needs to be able to understand that gap so that it can reassess what is the most important work to do in order to close that gap. If an organization can run this cycle of learning and adapting at a rate that is higher than its competitors, it will be able to outperform its competitors.
However, knowing that change is needed, and what needs to be worked on isn’t enough. The extent to which an organization is capable of constantly working on what is the most important work, and the time it needs to make any necessary shift of focus, determines the actual agility of an organization. If the cost of changing focus is too high, it might make the product or service itself too costly and become commercially unviable. Additionally, if it takes an organization too much time to make the shift in focus, it will either be undertaken too late or not at all. Either way, when this persists that (part of the) organization will eventually go out of business.
Ramos and Pavlicenko have described this concept in their book Creating Agile Organizations stating that an organization needs to be adaptable if it aims to be agile. Adaptability being the ability of an organization to be adapted to current needs. According to Ramos and Pavlicenko the ability of an organization to adapt depends on three key factors:
1. Minimization of switching costs
The costs involved with changing direction, or switching from one activity to another, are called switching costs. For example, these costs manifest themselves as the time needed for a group of people to develop a new skill, the deprecation of an investment made for a product feature that no longer fits a current market need, or the time it takes a ocean containership to to change it’s course once it has reached its cruising speed.
The higher these costs, the lower the ability of an organization to change its direction. High investment up front, into large commitments with the promise of benefit in the far future decreases the willingness or ability of an organization to abandon such a commitment. An organization would be wise to commit to lower investments, with a payoff as near in the future as possible, so that abandoning those investments generates a smaller loss. The cost of switching stays lower.
For example, shortening iterations (that result in done product increments) lowers the switching costs for an organization by lowering the investment made. This increases its ability to change direction.
2. Minimization of transaction costs
Transaction costs are the unavoidable costs involved by the recurring activities that are needed to do the work.
For example, such activities are the recurring meetings a management team has, or teams running their Retrospectives, the daily performance of a set of tests assuring the quality of software doesn’t regress, or the price of having an ocean shipping container sail between the shores of two continents. These activities do not generate value by itself, but enable or improve the work that does generate value. Transaction costs represent the fixed costs involved in doing the work.
Transaction costs that are too high can express themselves as “the investment not justifying the yield”. A good example of high transaction costs is the delivery of a feature that took half a day to develop, but needs days of manual regression tests before it can be deemed safe to release. Teams almost always choose to pool such releases with other features, so that the relative transaction cost per release goes down. This might seem economic, but it actually only prolongs the time it takes for an organization to get feedback on the change it made.
As a result, transaction costs make an organization less able to respond to change. It puts a limit to the minimization of switching costs, because lowering the switching costs by shortening the iterations (while transaction cost remain the same) will result in relatively higher transaction costs. Hence, lowering transaction costs is an economic requirement for a business to be adaptable.
3. Maximization of the rate at which an organization learns
And lastly, and perhaps a more familiar one: the rate at which an organization learns from experience. For an organization to thrive, this rate needs to be higher than that of the competitor. This is closely related to the frequency of evaluating the outcomes against expectations. In Scrum for example, this is called the inspect & adapt cycle and its frequency is inversely related to the length of the iterations (Sprints): the shorter the iteration, the more opportunity there is to learn.
The process from starting an iteration to getting the product in the hands of the user, and receiving feedback is a feedback loop. The longer this feedback loop takes, the longer it takes the organization to know the gap between its goals and reality, and the greater the uncertainty of the size of that gap. There will be less transparency, and learning will be less effective.
Hence, the shorter the feedback loop, the higher the rate at which an organization can learn and the smaller the uncertainty about the size of that gap.
How about your adaptability?
What about your own organization? It doesn’t matter what framework for Agile development your organization has adopted. If your switching and transaction costs haven’t been dealt with, it will keep you from learning faster than your competitors. You will reap zero benefit from the effort you’ve put into it. It is worth looking around in your organization to see if you can spot high transaction costs preventing you from shortening your feedback loops, or whether there are high switching costs causing your response to change to be too late or completely absent. In my next posts I will provide some examples, how to spot them, and possible ways of how to deal with it.
Author: Jeroen Valkier
