Reduce transaction costs: start working Agile
In the last decade, the Agile way of working has dramatically decreased transaction costs in the development of new (IT) products. This blog explains what transaction costs are, what Agile is and why transaction costs are lower in Agile development processes than in traditional ones.
In the early 1920’s a couple of chain grocers in the United States experimented with diversifying their products. They wanted to offer customers more products in one building. In the beginning, one of those stores consisted of a separate baker, grocer, fishmonger and butcher. The chain grocers realized that regular negotiations with these entrepreneurs, about all sorts of things, took up more time than need be. So, they hired them. Products from all departments could now be delivered at once and by one transport company. As a result, transportation costs dropped, followed by the prices. Customers really liked the concept and while the number of stores declined, sales increased. This showed that the concept of supermarkets are successful because it is simply easier and cheaper to shop for all your groceries in one location. This implies that supermarkets significantly decreased transaction costs for themselves and for people who shop for their daily groceries.
In 1937, in his article ‘the nature of the firm’ Ronald Coase already argued that businesses come into existence when it is too costly to continuously find the right people or products, bargain about the prices and monitor the performance of the supplier. In other words, a firm is a means to draw up long term contracts (hire entrepreneurs), when short term contracts are no longer profitable (regular and continuous negotiations). Hence a firm, like the supermarket, is primarily a means to lower transaction costs.
Transaction Cost Theory
In his article ‘The economics of organization: The Transaction Cost Approach’ published in 1981, Oliver E. Williamson claims that transaction costs theory exist when unnecessary costs have to be made by firms in order to generate a successful exchange with another party. Each business transaction, especially between a client (or employer) and its supplier (or employee), comes at invisible costs, time and effort, that could have been invested in something else.
These invisible costs are divided in three types: information costs, contract costs and monitoring costs. Information costs refers to time and cost invested in finding the right supplier and client. The rise of internet and applications like LinkedIn decreased the information costs tremendously. Once a supplier is chosen, the client and supplier have to agree on the price and quality of deliverables. Drawing up a contract that includes all necessary details for the business arrangement to succeed takes time. The more complex the product or service, the higher contract costs will be. For example, it is relatively easy to check if a supplier has delivered all 10 hammers that you ordered. But how do you evaluate if those hammers are sustainably and fairly produced? Once a contract is signed a client monitors if a supplier honors its commitment throughout the contracted period. As clients often do not trust suppliers, effort and costs invested to successfully monitor suppliers are high. Logically, finding a party that you trust lowers monitoring efforts significantly.
Over the last few years, various methods have been introduced to optimize business performance and business efficiency. The most notable is ‘Agile working’. In an Agile culture a project is broken down into bits of user functionalities that can be prioritized and are continuously produced and presented in short cycles (sprints). A product is created incrementally from the start of the project instead of trying to deliver it at once. Consequently, the Agile approach reduces time-to-market (short cycles), improves flexibility (feedback loops) and increases customer satisfaction. I argue that Agile decreases both contract and monitoring costs. How, you might wonder, is explained below.
Agile simplifies contract negotiation
It is important to realize that clients often care more about the outcome, not necessarily how the supplier got there. Imagine that at company X the speed of the computers slows down the production process, therefore X wants faster computers. Company X is interested in the outcome, a faster computer, not what steps the supplier took to do so.
Traditionally, contracts fix scope, time and costs, while quality is flexible. In reality, when teams are developing new products or features the client obtains new information and better learns what it needs. Then the inevitable happens, a client wants to change the scope. As scope is fixed, changing it generally means adjusting the fixed and perfectly planned processes of a supplier. The supplier needs time to adjust and come up with a new plan, again with a fixed and perfectly planned scope. Consequently, contracts need to be altered continuously. Sadly, this time and money could have been invested elsewhere. Hence, in the traditional processes contract costs are high.
Business agility fixes quality, time and cost while the scope is flexible. When the scope changes, which is bound to happen, contracts do not have to be adjusted and the project continues without any lost time. Another benefit of a flexible scope is that a contract does not have to create certainty where there is none. As the end product is partly determined by a potential customer, the likelihood that the product is used is a lot higher too. I argue that, because scope is flexible in Agile projects, the initial contract is simpler and less likely to be altered. This saves both parties a lot of time and thus lowers contract costs.
How Agile reduces costs of monitoring
A well known argument against implementing Agile working methods is that teams are not properly monitored. Managers often fear that teams become less productive. Another argument is that an agile organization is impossible to monitor. Indeed, one might wonder how, in an Agile process with autonomous teams, quality, price and costs are efficiently monitored. Remember, monitoring the scope is no longer necessary as the scope is determined by the clients during the development process. An Agile process consists of a number of iterations. After each iteration the client already reviews a Minimum Viable Product (MVP).
If the client realizes that some of the initial features of a product are no longer needed or it wants add a new feature, the team will simply adjust future iterations. Meanwhile, the product owner manages the expectations and input by the stakeholders during the development process. Monitoring the scope, in my opinion, happens organically and automatically in Agile. Subsequently, monitoring mechanisms regarding the scope do not have to be included in the contract. If a supplier does not honor its commitments the client will know soon enough.
Individuals are held responsible for the team output and quality, by product owners, product management, internal stakeholders and the like. Therefore, it is in each team members best interest to stimulate other team members to work hard and efficient, as the team output also serves as input for his own review. That is how team members are triggered to monitor one another.
For large scale adoptions, Agile has lean monitoring mechanisms. For instance, SAFe uses recurring release planning events where all product owners, product managers and team members discuss progress and prioritize what needs to be done in upcoming sprints. This monitoring mechanisms is both functional and helps managers to evaluate team performance. So, even though monitoring mechanisms in large scale Agile adoptions exist, their negative impact on efficiency (time better spend elsewhere) is significantly lower than in traditional mechanisms. Additionally, monitoring is not only done per team rather than individually, but all teams are also monitored at once.
In Agile working methods, most of the monitoring happens organically and automatically. The monitoring mechanisms that do exist are efficient and functional. Hence, I argue that Agile compared to traditional working methods has lower monitoring costs.
Agile establishes trust
I posit that the open dialog between the client and the team and the involvement of the client in the development process creates a relationship based on trust. Additionally, each team member is and feels responsible for the deliverables and does not have to be monitored separately. As mentioned before, trust between parties positively affects transaction costs, as strict contracts and intensive monitoring is no longer needed.
To conclude, working with Agile processes makes your transactions with other parties and the development of new products more efficient. However, these gains are often invisible at the start. If you are ever to face a choice between traditional and Agile working methods you should keep these invisible, though significant gains, through lower transaction costs.
Transaction cost theory refutes the argument that Agile teams tend to have low productivity because they are not properly monitored. It does, however, show that both contract costs and monitoring costs are significantly lower than transaction costs in traditional working methods.