Theory of Constraints and Software Engineering
By Chronologist Blog on Tuesday, December 27th, 2011
Features in QESP Newsletter
Volume 23 , Issue 4 - ISSN 1325-2070
In this post we will introduce the Theory of Constraints (TOC) and start looking at how it can be applied to software engineering management. TOC is most well known for its so called “Five Focusing Steps”, and often that process is referred to when trying to identify and deal with bottlenecks in Kanban for Software. However TOC has many other tools one can resort to in order to improve software engineering management. In particular, we will examine how Throughput Accounting (TA) can be used to take important management decisions.
Origins of the Theory of Constraints
The Theory of Constraints (TOC) is a management method developed primarily by Dr. Eliyahu M. Goldratt during the last 30 years, and first exposed as a business novel, “The Goal,” in [GOLDRATT-1992]. More recently TOC has been described extensively in the “Theory of Constraints Handbook “ by Cox and Schleier [COX-2010].
TOC originated from manufacturing, but has since been applied to engineering, project management, sales, accounting, marketing and other business processes. TOC is based on Systems Thinking, the Scientific Method and Logic .
The Scientific Method mentioned above is not to be confused with scientific management, which is a different management theory altogether. In fact, TOC has a strong appeal on people with mathematics, engineering or physics backgrounds, while it has not gained the same recognition from the people whom it should interest most, those with business, administration, management and accounting backgrounds.
Fundamental Concepts of the Theory of Constraints
TOC considers any business as a system transforming inputs into outputs. The inputs undergo a number of work steps and are transformed into outputs. The outputs are the products/services valued and paid for by the business’s customers.
The key tenet of TOC is that the system’s output capability is limited by one of the work steps, the system’s so called Constraint. The resource performing that work step, is the system’s Capacity Constrained Resource (CCR). Often a similarity is drawn with a chain: the chain (the system) is only as strong as its weakest link (the CCR).
Continuous Improvement and Theory of Constraints
TOC proposes a very simple Process Of Ongoing
Improvement (POOGI), consisting in the Five Focusing Steps (5FS) as shown here:
The 5FS is what TOC is most well known about. When systematically applying the 5FS, and effect-cause-effect logic thinking, the areas touched upon wills pan the whole business organization. [SMITH-1999] sums up TOC in two words: focus and leverage, stating that: “TOC guides management toward where and how they should focus resources to leverage return on investment.”
TOC’s prime principle is to focus on the weakest point of the organization, the constraint limiting throughput, and leverage all improvement efforts on the constraint.
Significance of Work in Process and Inventory
When work flows through a system, the placement of the CCR is (often) given away by work “ piling up” in front of it: you find queues of Work in Process (WIP). Like JIT, Kanban, and other methods, WIP and inventory are considered negative. [NOREEN-1995] explains: “ Excess inventories can increase cycle times, decrease due date performance, increase defect rates, increase operating expenses, reduce the ability to plan, and reduce sales and profits.”
The recent success of Kanban for Software is a testimony of why limiting work in process is so successful. (And it is not coincidental than Kanban for Software has been proposed by David Anderson, who first introduced TOC for software too.) The whole idea is to identify and manage what constitutes the inventory of software development.
Inventory in Software Development
If TOC is to be applied to software development, a relevant question is: What is inventory in software development and how can it be measured?
[ANDERSON-2003] first tried to use TOC for managing software, and states inventory is defined “through measures of client-valued functionality. […] The ideas captured as functional requirements or a marketing feature list represent the raw material for the software production system. Requirements represent the ideas being transformed into executable code.”
Client-valued functionality can be expressed in different ways, depending on the software methodology used. A unit of inventory could be, for instance:
. A Use Case in UDP [a.k.a. RUP].
. A Story Point in XP (eXtreme Programming).
. A Feature in FDD (Feature-Driven Development).
. A Backlog Item in Scrum.
. A Function Point in traditional SDLC structured methods.
In short, “ A unit of inventory is an idea for a client-valued function described in a format suitable for use by software developers. “ In simpler terms: Inventory is the to-do list of client-valued functionality – no matter how the to-do list is represented.
Note here that the stress is on “ client-valued “ functionality because TOC is much concerned with “business value.” Unlike Agile processes, TOC makes it mandatory to quantify such business value. The value is represented as estimated revenue during planning and development phases, or actual revenue when in production.
Throughput Accounting
Throughput Accounting (TA) is TOC’s approach to accounting. In [ANDERSON-2003] we also find the first application of TA to the field of Software Engineering. Anderson’s ideas have been further expanded by [RICKETTS- 2007] who applies the approach to the professional, scientific, and technical services businesses, and therein to information technology and software engineering.
Editor’s Note : The original provides background on TA and explains how TA differs from Cost Accounting (CA), noting:
One key tenet of TOC is this : Reducing cost is limited, while increasing throughput is potentially unlimited . An excessive focus on cost reduction can jeopardize the company’s capability to deliver, and instead it will decrease throughput, with much more devastating consequences.
The original goes on to show how TA can be reconciled with Cost Accounting. )
Throughput Accounting for Software Engineering
Software engineering is intangible, while the origins of TOC are from the very tangible manufacturing industries. To acknowledge these differences, [RICKETTS-2007] identifies a Throughput Accounting for Software Engineering (TAE )
(Note: Ricketts also defines a more extensive Throughput Accounting for Software Businesses covering sales and research in addition to software engineering proper, and also distinguishing between selling a software product and a software service. He further distinguishes between TA for software engineering and other intangible service businesses which are different because more labor based, and less automated and reusable. For this discussion, TA for software engineering alone is sufficient.)
TAE is defined as follows:
. Throughput: TE is the rate of cash generated through delivery of working code into production […] It is computed as sales price minus direct costs, such as packaging, delivery, installation, training, support, and networking.
. Investment: I is all money invested in software production systems plus money spent to obtain ideas for client-valued functionality. It thus includes software development tools and requirements gathering. […]
. Operating Expense: OE is all money spent to produce working code from ideas. It is primarily direct labor of software engineers, but it also includes selling, general, and administrative costs.
The following performance measures are computed exactly the same way :
. Net Profit: NP = TE – OE
. Return on Investment: ROI = NP / I
A simple view is sufficient to draw meaningful conclusions:
NP is the difference between the revenue generated and the implementation cost; ROI is the ratio between NP and requirements gathering costs (and considering the cost of the software production system already amortized). To increase NP and ROI, you must increase TE while decreasing I and OE.
[RICKETTS-2007] suggests this is done “by gathering requirements rapidly yet accurately, creating software that customers value, and eliminating waste, which is composed of requirements and functions that are discarded before software enters production.” So minimize time spent gathering requirements and planning, and minimize the scope of the project.
These principles, derived from TOC’s systems-thinking approach and supported by TA, are comparable to what is endorsed by Agile and Lean processes. On the contrary, the application of these principles to traditional software processes is in conflict with the need to identify “all possible” requirements upfront.
Example: Decrease Operating Expense by Avoiding Feature Creep
You can reduce the OE by discarding requirements before starting implementation work, as described in my contribution to [SMITE-2010], where I presented a value based technique for triaging requirements expressed as User Stories, and estimated in terms of Story Points (as proposed by [COHN- 2005]).
Each Story Point was associated with a corresponding estimated revenue value, which was recomputed after eliminating unnecessary stories. In an agile setting with CA, the “production cost” of a story point is always the same; the only way to “increase value” is to lower the cost per story point, or increase velocity/productivity. With TA, instead, increasing T in terms of the story point’s economic value is different. The stories “worth less” are eliminated. After eliminating a single story, you reduced the OE (the effort to produce the software).
Note:
. From an Agile perspective, you “maximized the amount of work not done” as stated in one of the twelve principles of the Agile Manifesto [BECK-2001].
. From a Lean perspective, you applied the principle of eliminating waste.
By recomputing the value of the story point, the overall value of the project increases. Reducing scope, project duration and time to market decreases; therefore ROI not only increases, but gets realized much sooner.
(Editor’s Note: The original provides further Example s for Decreasing Investment and Operating Expense with Open- Source Software and for Increasing Throughput by Targeting the Long Tail (i.e.by focusing on the “Long Tail” market niche.)
Considerations on Combining the Examples
The strategy of embracing an Open-Source project decreases OE (just like outsourcing), because there is less work to be done in-house. At the same time (and unlike outsourcing), it also reduces I because you don’t need a requirements gathering phase to define the part of functionality delivered by the Open Source software (a part from the activity of evaluating the fitness for purpose of the Open-Source software), nor to invest in any additional equipment to support the development of the platform. Outsourcing the development of such functionality, rather than exploiting Open Source software, increases OE (but less than doing the development in-house).
By choosing to target a long tail niche market and defining the scope of functionality covered respectively by the Open- Source component and your proprietary development, you give the proprietary code a positive impact on ROI, according to TA. Choosing Open-Source allows to reduce I. Limiting the scope of the proprietary code reduces OE. The strategy to target a niche market, increases T because higher prices can be commanded.
Adopting Open-Source software is seen as I; with the very beneficial quality of being zero. Though there is a component of OE too, to cover the new kinds of activities that come with Open-Source Software. Using Open-Source Software is not a zero cost operation. Only the acquisition is zero cost. Consider the total cost of ownership, and at least the expenses for gaining the knowledge about how to use Open-Source Software. Often it also means assigning development resources for integration, extensions and maintenance of Open-Source Software. Time must be invested in tracking down problems in Open-Source Software, especially (as is often the case with smaller Open-Source Software solutions) when support is not available. The sum of all these additional OE is negligible compared to the effect of the I we are focusing on. Recall: I appears as the denominator in the ROI ratio, while OE is only a factor in the numerator difference. Finally consider that the work on the proprietary code is all covered by OE.
Software Production Metrics in Throughput Accounting
[RICKETTS-2007] suggests using the following metrics specifically for software production:
. Production Quantity : Q = client valued functions delivered
in working code
. Inventory : V = ideas + functions in development +
completed functions
. Average Cost per Function : ACPF = OE/Q
The ACPF was originally presented by [ANDERSON-2003], who also defined the:
. Average Investment per Function : AIPF = I/Q
Ricketts suggests “Q, V, and ACPF correspond to T, I, and OE, respectively.”
However, I consider this imprecise, and propose to add an
Average Throughput per Function ATPF defined as:
. Average Throughput per Function : ATPF = T/Q
The ATPF metric, rather than Q, is more correctly mapped to T. Using just Q appears to consider cost (the implied assumption being that cost is proportional to quantity) as prevalent over throughput.
As illustrated in the example about decreasing operating expenses by avoiding feature creep, the ATPF metric has important practical applications. To be precise, in the case cited in that example, the Average Revenue per Story Point was used; but revenue per story point/function can be considered as a first approximation of ATPF. The throughput per story point just subtracts a constant factor, the totally variable costs, from the revenue figure. Triaging stories and eliminating those “worth less” increases both numbers, so the effect on the decision making is unaltered by using the simplified metrics.
Take advantage of these software specific production metrics derived from TA. In particular focus on increasing the ATPF, and on decreasing the AIPF. Consider the ACPF last.
Throughput Accounting’s Effects on Delivery
The different perspectives given by TA and CA with respect to software engineering, are described by [RICKETTS-2007] as follows: “TAE is a radical alternative to Cost Accounting (CA), which focuses more on OE than T or I. As each software engineering task is performed, CA uses time sheets to add the cost of those tasks to the recorded value of the software being produced. So the longer a project lasts and the more effort it consumes, the more CA values the software asset. This creates no financial inventive for early completion, even though the business value to the client of undelivered software tends to go down with time.”
In TOC, this is very different, because “TAE does not record value added. It simply records I at the beginning of the project and T at the end. TAE dispenses with time sheets because effort is a fixed cost captured in OE. Thus, the longer a project lasts and the more effort it consumes, the more TAE increases its OE and decreases its T. This creates incentive to complete projects on time or early because that maximizes NP.” This line of reasoning gives financial support to Agile/Lean processes that promote early completion and frequent delivery on the basis of technical reasons (to better capture and live up to the client’s needs). TA creates incentives to complete projects on time or earlier for financial reasons. Record I at the start, and T at the end. All effort is represented as a fixed running cost by OE.
Throughput Accounting’s Effects on Other Common Processes
TAE also provides a different viewpoint than CA on some common circumstances in software engineering, described by [RICKETTS-2007]:
. When turnover occurs, CA just measures the cost of replacing lost software engineers. TAE captures this cost in OE, but TAE also measures the loss of T on the constraint, which can be many times larger because it is output lost by the entire organization.
. When hiring occurs, TAE sees no increase in T unless the hiring is for the constrained resource. That is, hiring a non constrained resource increases OE without increasing T. When outsourcing occurs, it decreases OE, but it may also shift which resource type is the constraint. If the constraint is outsourced, the decrease in OE may also decrease T.
. When projects are constrained by schedule, budget, resources, and scope, each constraint needs a buffer to protect it from uncertainty, but buffers increase OE without increasing T. Formal methodologies and process maturity certifications attempt to reduce uncertainty and thereby reduce buffer sizes, but methodologies and certifications themselves increase OE.
Conclusions
The simplicity of the TOC logic reveals a general strategic direction, which can be verified and validated with the simple metrics of TA (T, OE and I). TOC gives strong arguments to pursue or not any strategy under consideration, even without estimating or calculating costs and revenues, but only through logic. TOC’s strength is in the simplicity of its approach to decision making, when supported by TA; it is an advantage because it comes to a decision in less time.
TA can be used to take management decisions on all business processes, including turnover, hiring, outsourcing, choice of methodology, and so on. The trick is simply that of relating any decision to T, OE and I, in order to make an informed and financially sound decision.
(Editor’s Note: The following is an extract from a Jul 27th, 2012 post in the Software Business & Entrepreneurship Chronologist Blog. The original is available at http://chronologist.com/blog/2012-07-27/theory-of-constraints- and-software-engineering/ )
– See more at: http://qesp.org/articles/theory-constraints-and-software-engineering#sthash.sYMStSqi.dpuf