Relating Agile Methodologies to Principles of Finance
Transformative Leadership @ Scale Series
Introduction
In my introductory article on Transformative Leadership, I discussed that the goal of any IT or Operational organization should be to maximize Return on Investment (ROI). When we look at Agile as a means of implementing systems and processes, we can align Agile concepts to a number of key concepts in the financial industry. Specifically, we can align concepts that relate to securities trading and investments. At the core of both sets of concepts, are risk-based and value-based principles, which when effectively established, have a significantly positive effect on ROI.
Risk-Based Principles
The two most relevant risk management principles are: (1) Liquidity and (2) Project Duration
Liquidity
The Investments Paradigm
Liquidity refers to the ease with which an asset, or security can be converted into ready cash without affecting its market price. In other words, if we can buy and sell a security or asset at a high frequency with low transaction costs, without impacting the market’s value, we have significantly reduced our risk. At its core, liquidity is established by
· Increased demand represented by a large number of buyers
· Increased supply represented by a large number of sellers
· Low transaction costs
· Efficient execution of transactions
The Agile Paradigm
Now let’s look at Agile methodologies through the prism of liquidity. Fundamentally, Agile is based off of introducing small units of work, at a very high frequency, resulting in new functionality being introduced without instability to the current environment. The units of work can be related to both, requirements gathering or implementing new modules for systems or processes. The thought behind this is that failure is ubiquitous in software development, so we should fail in small sizes as early as possible, then assess and adapt.
If we are going to work in small units at a high frequency, then the units of work and the resources performing the work must be readily available. Having units of work being readily available means that the work is properly sized and well vetted. Readily available resources mean that the team members are able to move to and from tasks with the lowest learning curve possible. In addition, the resources must be able to perform the work with minimum overhead. If there are a number of manual tasks involved, then the frequency at which the overall work is completed is significantly reduced. Said differently, at its core, Agile works if we are able to establish
· Large number of small units of well-defined work (Demand)
· Large number of resources capable of performing small units of work (Supply)
· Low context switching costs (Transaction Costs)
· Low overhead of performing the work (Efficient Execution)
An illustration of how we can establish liquidity within our software development practices.
The result is an environment which allows developers (the supply) to align with highest prioritized projects (the demand) continuously at low switching costs, in a manner that is cost and time effective.
Project Duration
The Investments Paradigm
Duration measures how long it takes for an investor to be repaid the bond’s price by the bond’s total cash flows. Often confused with the time to maturity, duration is a quantifiable measure which takes into account the frequency and size of the cash flows, throughout the life of a bond. The more frequent and larger the cash flows, the lower the duration, which is most often less than the time to maturity. The principle behind duration is that it is advantageous to have your cash returned over time, as opposed to larger amounts towards the bond’s maturity. Let’s say Bob lends money separately to both Anne and Walter at the same annual interest rate, for the same period of time. However, Anne pays back Bob in small, but frequent increments, while Walter pays Bob in less frequent but larger increments. The risk that Anne poses to Bob is less than the risk that Walter poses, even though the total payments are the same. The fundamental reason is that if both Anne and Walter stop paying Bob sometime between Anne’s most recent payment and Walter’s next payment, Bob would have received more of his cash back from Anne.
The Agile Paradigm
In software development, currency comes in two forms: (1) Information/Knowledge and (2) business value delivered by the system or process. Like the cash flow of a bond, the sooner and more frequent we receive these two forms of currency, the more return on investment we will receive, even if the units of currency are small and spread out over time.
Information/Knowledge
Information and knowledge are obtained in two contexts: (1) the requirement from the user is understood by all vested parties, (2) the requirement has been met by the implementation. Most system implementation fail, not because of poor technology, but rather the inability to confirm those two information points in a time effective fashion. In fact, often the requirement is not fully understood by the requestor, so the sooner the requirement can be shared and understood in the form of specification and eventual implementation, the sooner the requestor could confirm his request. Breaking requirements down into smaller components, which are reviewed and implemented in a frequent fashion, enables the requestor to confirm the request more efficiently.
Business Value Delivery
When aspects of the system are delivered and used, the benefits are realized in the form of lower risk, in addition to higher overall value. We should strive to deliver functionality frequently, even if it’s in small units. Doing so reduces the risk of the project because the users have “functionality in hand”. That risk can be viewed as the project’s duration. Let’s take two projects of the same exact scope, and have one of the projects deliver all the modules at the very end, while the second project delivered the modules throughout the project life cycle. Even if, when measured in overall time, the second project took incrementally more time than the first, one could argue that the second project had a lower risk because due to continuous delivery of value. Even though it had a longer overall time than the first project, the second project’s duration was lower. Looking back at the loans example, Anne’s payment structure looks more like an Agile delivery, while Walter’s payment structure is closer to waterfall. If the project is defunded sometime between the Agile project’s most recent delivery and before the Waterfall project’s next delivery, the Agile delivered project will have more sustainable functionality.
Illustration of the risk profiles of various degrees of agile delivery.Added Benefit: Lower Opportunity Cost
Another benefit from Agile deliveries can be seen in the context of opportunity costs, which is the cost realized when a group foregoes a value-adding opportunity because of its commitments of funds and resources to a current project. However, because Agile delivery offers sustainable value in the form of working modules delivered throughout the project lifecycle, a group can reallocate funds to another project, almost any time throughout the initial project’s lifecycle and still obtain value from it. As a result, the opportunity cost of the initial project is lower.
Value Based Principles
The two most relevant value-based principles are: (1) Net Present Value and (2) Time Value of Money / Functionality.
Net Present Value
Investments Paradigm
The value of an asset is maximized when the initial investments are offset by the ongoing cashflows received. In finance terms, this is called maximizing net present value (NPV). This is calculated by subtracting the sum of the future cash flows, discounted to its present value, from the initial investment. When the sum of the discounted cash flows is greater than the initial investment, the investor receives a positive NPV.
The Agile Paradigm
In the perfect world, systems could be built with little investment in non-functional requirements, and little to no ongoing support and maintenance. However, we do not live in the perfect world, so we need to decide how much upfront investment in non-functional requirements should be made in order to reduce ongoing maintenance. The right balance is struck when ongoing savings in maintenance, more than offset the initial investment. Similar to financial investments, investments in systems obtain a positive NPV when the discounted value of the accumulated savings in maintenance (ie the savings present value) is greater than he initial investment in non-functional requirements. The below diagram illustrates this concept.
Time Value of Functionality
The Investments Paradigm
The time value of money (TVM) is the concept that money you have now is worth more than the identical sum in the future due to its potential earning capacity. This core principle of finance holds that provided money can earn interest, any amount of money is worth more the sooner it is received. Alternatively, money invested today, will have a higher value in the future because of compounded interest.
The Agile Paradigm
Similar to Time Value of Money, it is better to receive components of a system sooner than wait for the entire system. Alternatively, the sooner you get value from the system, the longer you are receiving value, and therefore the higher the total value received from the system. I call this the system’s Time Value of Functionality. Assume a system is in production for 15 years. If the first module is released after the second month of the life cycle, its time value is 14 years and 10 months. If the second module is released in the fourth month of the life cycle, its time value is 14 years and 8 months. And so on…The sooner the module is delivered the higher its time value of functionality. The larger the number of modules, and the longer they are in production, the greater the system’s overall Time Value of Functionality. The below diagram illustrates that the system delivered with the highest level of agility has the highest accumulated time value of functionality.
Bringing It All Together
As mentioned throughout the Transformative Leadership series, the goal of all efforts should be to maximize Return on Investment (ROI). Within the domain of system and process implementation, ROI can be maximized by using concepts inherent in the financial domain, which are built off of the principle of maximizing value, while minimizing risk. By establishing a liquidity-based environment and focusing on reducing a project’s duration, overall risk is minimized. Simultaneously, making the appropriate types of initial investments, that reduce ongoing maintenance costs, the value of the project increases. In addition, delivering functionality earlier, even in smaller units, drives up the value of the project.
