Thursday, July 29, 2004
Transparency, Alignment, Productivity & Governance
Making the Business Case for Agile Management
- Simplifying the Complex System of Software Engineering
Download the Paper [PDF format 2,703K]
Download the Slides [PDF format 682K]
Introduction
Software has become a vital part of business competitiveness. Almost all products have some software component and businesses which do not require software in their product or service, still rely on it heavily to manage their value chain and communications. Software development has become material to the accounts and performance of almost ever major company.
In this first decade of the 21st Century businesses are increasingly under pressure to perform better. Globalization and improving supply chain management are forcing companies to look again at how they can be more competitive. How they can do more with less and how they can deliver products to market faster and gain a competitive advantage. Recent changes in rules for doing business mean that firms must demonstrate that they are well governed and making appropriate use of shareholders funds.
As a result of all this, software development is in the spotlight. For the first time, there is a desire for software engineering to demonstrate transparency, alignment, with better productivity and demonstrable good governance. Senior executives will no longer accept the opaque cloud of traditional software development. There is a need to understand what software developers are doing and to insure that those activities are aligned with the business goals and stockholder interests.
To achieve this, the way we manage software engineering activities has to change. This paper makes a case for an agile approach to management which focuses on delivering value effectively and efficiently and has its foundations in popular and established branches of management science.
Management Science
Management science started with the British economist Adam Smith who worked during the start of the industrial revolution. He wrote in his seminal work, “The Wealth of Nations” [Smith 1776] that what separated advanced industrial economies from backward craft-based economies was “specialization”.
The man who really got management science started was Frederick Winslow Taylor, who worked for Bethlehem Steel around the turn of the 20th century. He created “time in motion” studies which sought to analyze the efficiency of Smith’s specialist workers. Henry Ford was a fan of Taylor’s work and he used his ideas [Taylor 1911] to create the assembly line (in 1917) – which minimized inefficient time-in-motion and maximized local throughput for individual workers. Extreme specialization was a boon for Ford as it minimized training and allowed new (often illiterate) employees to become effective very quickly.
In the 1950’s, Peter Drucker taught the world that there was only one value for a product – the price which the consumer was prepared (or able) to pay. The idea of cost based pricing was dead. 20 years later, Michael Porter refined this idea and introduced the notion of a value-chain. The idea that a chain of workers or a chain of suppliers each added value to a raw material until it was eventually delivered to a consumer. The ideas of Drucker and Porter are essential to the notion of “value creation”.
Arguably the next giant leap in management science taught in business schools came with the publication of “The Fifth Discipline” [Senge 1990]. In this text Peter Senge, teaches the world that businesses (and value chains) are complex systems. To maximize the effectiveness of a business, the system must be considered as a whole rather than the sum of its individual parts. This was the critical break from Taylor’s theories which existed under the assumption that optimizing locally (time-in-motion) would lead to a global optimum. All mass manufacturing was grounded in Taylor’s theory. Mass manufacturing was losing in the marketplace to an alternative approach from Japan – known in the West as “Lean”. The application of general systems theory to software engineering was later proposed by Jerry Weinberg [1992].
Understanding Variation
In the 1920’s another branch of management science was forming under the guise of industrial engineering and quality assurance. Walter Shewhart studied variation in manufacturing and divided it into two types which he called chance cause and assigned cause variation [Wheeler 1992]. Shewhart created control charts (see figures 8 through 10) to monitor the variation in a process within defined control limits. Data points outside his limits (which were based on 3 Sigma) were indicative that the process had moved out of control and that the cause was either an unstable system with excessive and unpredictable variation, or an identifiable assigned cause which could be eliminated through management intervention. For example, the difference between the quality from one worker to another was an assignable cause and could be addressed through training. Edwards Deming, a disciple of Shewhart was later to rename the types of variation as common cause and special cause. It is these terms with which we are familiar today.
Understanding variation and correctly identifying it as common or special cause is vital to the execution of good management. Correctly identified common cause variation shows the endemic nature of the system. To reduce common cause variation, the system must be changed. This requires management to invest in changes. Special cause variation, on the hand, has an identifiable assignable cause. Performing correctly, management can assign resources to eliminate a special cause problem. The servant model of management suggests that the proper job of management is to provide the resources to allow work to continue without hindrance. Special cause problems hinder progress and put business promises at risk.
Wheeler’s 4 States of Control
Another descendant from the Shewhart school is Donald Wheeler. He has modeled what he calls The Four States of Control [Figure 1].
Figure 1. Wheeler’s 4 States of Control
Wheeler’s model divides the world into two rows – common cause and special cause – and by two columns – conformant and nonconformant quality. The meaning of conformant quality is defined by the market within the particular industry. For software engineering we choose to define conformant quality as “on-time, on-budget, with agreed scope, and a quality level of x defects per hundred function points”. To move from the right hand column to the left hand column, we must reduce common cause variation. To do this we can either, improve our system or lower our standards – redefine the meaning of conformant quality.
The notion of special cause variation creates a barrier to control. If special cause variation is allowed to affect a system it is never under control. Hence, to move from the lower row of the Wheeler chart, it is necessary to eliminate (not merely reduce) special cause variation.
Six Sigma
It is easy to see how the Wheeler chart helps us to understand the underlying philosophy of Six Sigma. Six Sigma is asking us to create a culture of continuous improvement through a focus on reducing variation. We can see instantly from Wheeler’s matrix that we can improve by eliminating special cause variation. This means that we must identify issues early and work them out before they affect the critical path. We can then see clearly that further improvement is achieved through reduction of common cause variance. Both DMAIC and DMADV processes relate directly to moving a software development process from right to left on the Wheeler matrix. DMAIC can be used to measure variance in estimation against analysis artifacts such as Features in FDD (see later section) and DMADV can be used insure code written delivers defined requirements. If a process suffers a special cause problem then the Global 8D process can be used to bring it back up into the top row.
Lean Thinking
Lean Thinking [Womack 1996] was a term coined by Womack and Jones who spent a considerable number of years studying the success of the management approach at Toyota. Lean in a combination of the Just-in-time inventory system invented by Taiichi Ohno and Edwards Deming’s approach to Quality Assurance. Deming in turn had learned his approach to quality from the Statistical Process Control chart approach of Walter Shewhart. Lean Thinking was an attempt to capture the basic principles and values behind the technique. These are: the self-organizing flow of value (Kanban); the elimination of waste (muda); build integrity in; design out the possibility of failure; rigorous quality assurance with empowered workers who have permission to stop an assembly line in order to fix a quality problem; reduce inventory; reduce lead time; and think holistically about the system.
The Patterson Design Model
With Accelerating Innovation [1993] Marvin Patterson introduced a concept for modeling the design process. He asked us to envisage that design was a process of information discovery. Before a design is started there is little or no information, perhaps only a vague thought. As the design emerges there is gradually more and more information and less and less uncertainty until the design is complete.
Mary Poppendieck [Poppendieck 2003] suggested that software development can be understood with the same model. In other words, all software development is a “design problem”. This would allow us to model the flow of value through a software engineering system as the gradual reduction of uncertainty and the discovery of more and more detailed information until working code which passes appropriate quality control tests, is produced.
Design is Perishable
Writing in his 1997 book, Managing the Design Factory [1997] Donald Reinertsen developed the ideas of Patterson a little further by introducing two concepts. The first observation was that design-in-process inventory could be tracked using Cumulative Flow Diagrams [Figure 2] used in Lean Production. The second and perhaps the most valuable insight was that the value design information depreciates over time. There are several reasons for this. The main one is that information need only be created once, as the cost of replicating it is near zero. If design is information then the time it takes a competitor to duplicate the design, is the time in which the design (and its associated information) has a differentiating value. Design information is also perishable because of possible changes in the marketplace – fashions change and so do laws, regulations, materials, supply components, distribution networks and business models. To have real value a design must be appropriate for its time and it must come to market within its window of appropriateness. If software is design then the same must be true of it. The requirements for a software program must be perishable. Hence, the faster the requirements can be realized as working code and brought to market, the more value will be delivered. Reinertsen’s and Poppendieck’s observations tie software engineering firmly to the principles of Lean.
Figure 2. Cumulative Flow Diagram
The Theory of Constraints
Senge wasn’t the first management guru to advocate systems thinking. In 1984, Eli Goldratt published “The Goal” which made just such an argument for manufacturing production. Senge describes a system archetype which he calls “limits to growth”. All “limits to growth” systems are eventually limited by some constraining force. The constraint exhibits itself as an flatten curve if the process is graphed [Figure 3]. Goldratt’s argument was that management should focus on removing that constraining force and growth would continue until another constraint started to limit it. Again management should focus on removing the constraint and productivity growth would continue. And so on for ever – a process of continuous improvement focused on the constraint which was limiting the growth of productivity.
Figure 3. Idealistic S-Curve
The Essence of Agile Management
Agile management is about management science applied to software engineering for the purpose of delivering transparency of process and progress, alignment of the day-to-day activities of software engineers with the best interests of the business and its stockholders, continuously improving productivity, and the correct information with which to make resource allocation decisions, ultimately delivering good governance and best use of shareholder funds.
Value Creation
Employees must understand what their organization does to add value to the overall business. If the development group is part of product design division then the developers must understand what business value their code will deliver. They must then focus on delivering that value as effectively as possible.
Value creation is at the heart of management science. In software development engineers add value by transforming ideas for products and product features into working code. They do this by a continuous process of information discovery and uncertainty elimination. The more precisely an idea can be described; the closer it is to a mathematical form such as program code.
Objectivity and Metrics
Good management is objective. It is based in blunt reality. Good agile managers must know and accept reality. In order to make objective decisions, based in reality, a manager must know the current reality of a business. In order to do this, system metrics must be gathered. Without facts and data, there can be no management.
In the software world, people are skeptical of metrics. For years many metrics have been gathered. Two favorites are number of hours worked on an activity – the weekly timesheet – and number of lines of code written. Another popular one is number of defects per thousand lines of code. Many agile methodologists are openly critical of metrics gathering initiatives and put scorn on the activity.
However, the correct metrics can be effective. This is not so much to say that 30 years of management theory in software engineering is wrong but rather the project management aspects of software development have been misguided. They failed to focus on the most important thing – value creation. If software methodologists had been better versed in established management science then methods which focused on value creation rather than costs spent, e.g. hours worked, would have emerged earlier.
Reinertsen [Reinertsen 1997] describes ideal metrics as simple and relevant to the goal. That means they must measure value created. They should also be self-generating and provide a predictive (or leading) indication of performance. This can be achieved in software by tracking progress of information discovery against the fine-grained ideas for client-valued functionality in the requirements.
Focus
If a manager is to deliver results, he must focus. The Theory of Constraints teaches managers to focus on the constraining factor which is limiting productivity. This is very powerful because it does two things. It focuses management time and attention where it is most urgently needed – and we’ve all worked for managers who didn’t have enough time on their hands – and it focuses investment on the area which will generate the greatest return through the greatest increase in productivity.
By focusing on the system constraint, the overall productivity of the system is increased. The Theory of Constraints offers a method to achieve global effectiveness (value efficiency) rather than the local cost efficiency of earlier Taylor inspired management methods.
It is possible that many early attempts at management metrics for software development were based in the local efficiency and optimizations inspired by Taylor. Agile management is about value efficiency inspired by thinkers such as Peter Senge and Eli Goldratt.
Agile Project Management
Agile methods take their project management approach from the earlier Rapid Application Development (RAD) movement. In RAD, the deliver date for a project is set and the scope is varied if the combination of scope, budget and delivery date is under threat. Traditional project management as defined by the PMI Project Management Body of Knowledge (PMBOK) Critical Path method fixes the scope and allows the date to slide.
There is a basic problem with the traditional Critical Path approach – it fails to properly understand the underlying variability in the system. Consider the three variables – scope, budget and date. The date actually has the lowest desirable variance. We already know that the potential value being delivered is perishable and that the window of opportunity may be small. Often whole companies are organized around delivery dates with elaborate product launches, sales training, support training, and distribution channels primed to take the new product. It is highly undesirable to ship late. The budget is often under a reasonably strict tolerance and may also vary very little. There is a limit to the available funds even in very large companies. However, the scope has by far the greatest tolerance. The scope will change frequently as the market determines precisely what is needed. With the greatest variability, it makes most sense that it is the scope that should be allowed to vary. Following the Critical Path approach puts the project at the greatest risk because changes in the scope will force the delivery date to slip. If the delivery date is not to slip then a large buffer to absorb variability in scope is required. Large buffers are expensive. The more uncertain the scope – due to the newness of the problem domain or the inexperience of the team – then the larger the buffer
Quality definitions for software including ISO 9000-13 and the Software Engineering Institute (SEI) Capability Maturity Model (CMM) use a similar approach. In order to deliver compliant quality a project must deliver the desired scope on the desired date. Hence, with a fixed scope, it is necessary to build a big buffer in order to deliver compliant quality. The net of this is that compliant quality is expensive to achieve. In new domains where there is greater uncertainty in the scope and inexperience in analyzing it accurately, the delivery date and the quality compliance are always at risk. De Marco & Lister [De Marco 1999] have observed that organizations with high CMM ratings become risk averse. When we understand the variability in the project management control parameters and the metric for determining compliant quality, it becomes easy to see why this is true.
Probabilistic versus Deterministic Models
There is a simple explanation for the PMI approach to project management. It assumes that project management can be and is deterministic. There is an underlying assumption that tasks in a project plan can be defined and estimated precisely and that one task leads to another in a set fashion. The Gantt chart method used in traditional project management has no facility to allow for variance. It has no buffers.
Eli Goldratt [Goldratt 1997] proposed an alternative method of project scheduling which adopts a probabilistic approach to the problem. He calls it Critical Chain. The Critical Chain approach uses buffers for the anticipated variance in each task but properly understands the mathematics of probability and provides appropriately sized buffers for the whole project and feeding chains of tasks in the project plan as shown in the Critical Chain PERT Chart [Figure 4].
Figure 4. Critical Chain PERT Chart
Feature Driven Development
Feature Driven Development [Palmer 2002] is a method of Lean/Agile development which was created in the late 1990s during a large IT project at United Overseas Bank in Singapore. It consists of 5 process steps each of which is defined with its own ETVX (Entry, Task, Verification and Exit criteria template) [Figure 5].
Figure 5. Five Processes in FDD
FDD achieves compliance with Design for Six Sigma’s DMADV process through its enforcement of its 5 ETVX processes.
Process 1 – Domain Modeling
Domain modeling involves a cross-functional team who work with domain experts to analyze the problem space and construct a UML class model which represents the objects and their relationships in the domain. This model is used as a blue print for the software and as a communication tool within the project. The language of the domain model becomes the dictionary for the project. The objective of the modeling stage is to provide a consensus understanding of the problem domain and to facilitate the writing of very precise requirements which follow a strict template. These precisely worded requirements are known as Features.
Process 2 – Feature List
In the second process, the lessons learned from the domain modeling exercise are used to re-write the requirements, or scope, as a Feature List. Each Feature is expressed using a template
<action> the <result> of|to|from|for|with a(n) <object>
e.g. calculate the interest for the bank account
There are a few types of Feature which do not easily conform to the template,
e.g. has the subscriber requested privacy protection
Features are written at the granularity of functions in structured or object oriented methods. Given that the domain modeling exercise was a broad sweep across the desired functionality it is not always possible get a precise list of all Features at this stage. However, to recall Patterson’s design model, we are adding value by gradually increasing the amount of information we know about the desired system. Our Feature list may not be precise but it is correct within some tolerance. We must buffer for the uncertainty associated with missing Features or “dark matter” [Anderson 2003].
Features are grouped into Feature Sets and Feature Sets into Subject Areas. Loosely speaking a Feature Set is a group of Features which can be system tested together while a Subject Area is potentially customer deliverable and can be product tested. Hence, Feature Sets provide the opportunity to drop working code to quality assurance in an incremental fashion. The groupings of Feature Sets will be used to produce a Critical Chain schedule in process 3.
Process 3 – Planning
The third step in FDD involves determining the desired order of delivery for Features in the project. Features should be prioritized and estimated based on their complexity. An estimate of the total number of Features possible within the desired delivery date should be calculated. The total should include a buffer to protect the delivery date from variance in the complexity estimation and from the emergence of dark matter. The Features which make the cut are then cast into a Critical Chain schedule based on their Feature Set grouping. The accuracy of the analysis and estimation of Features and Feature Sets in the plan will be tracked with a cumulative flow diagram and associated control charts. This enables the Six Sigma DMAIC process with FDD. If any changes were made to the method of software engineering, the improvement could be measured using the techniques described in the next section, Transparency and Governance.
Process 4 & 5 Design and Build in Small Batches
The construction of working code then proceeds by allocating small batches of Features to a single Chief Programmer who will form a small team of developers to complete the work. A small batch is defined as a set of Features which can be completed within two weeks or less. Complexity is controlled by the small batch size. Reduced complexity should lead to improved quality and less communication overhead amongst the team. Design and Build consists of six milestones: walkthrough, design, design review, coding, inspection and unit test. The progress of each Feature through these milestones is recorded and plotted on a Cumulative Flow Diagram which together with the Critical Chain schedule is the main control feedback mechanism for the project.
During processes 4&5, the team will meet briefly every morning where they will record Feature Milestones achieved since yesterday, work likely to finish today, and agree new work allocations – the release of inventory for design or build. If any Features have become blocked the reason will be identified and an issue entered into the log. The project manager will become responsible for resolving the issue before the blocked Feature uses its associated schedule buffer. In this way, FDD uses daily meetings to achieve the Global 8D Method in Six Sigma for elimination of special cause variation.
Transparency & Governance
Feature Driven Development projects are tracked using a web based knowledge management system which is used to produce a regular project dashboard [Figure 6].
Figure 6. FDD Knowledge Base Dashboard
A drill down of individual Features is available [Figure 7].
Figure 7. Feature Set and associated Features showing the six individual milestones
This data can be used to plot a cumulative flow diagram (CFD) similar to that in Figure 2. The CFD can be used for two purposes. It reports progress in terms of earned-value and it can be used for day-to-day health monitoring of the project including the identification of emerging bottlenecks.
From the Theory of Constraints Drum-Buffer-Rope solution for inventory flow problems [Goldratt 1984], the essential control parameters are the capacity (or production rate) of the constraint and the rate at which new material is allowed to enter the system. From the Critical Chain solution for probabilistic project scheduling the important control parameter is usage of the project buffer. All of these can be derived from the Feature milestone CFD plot. To make these more clearly understood they can be plotted using Control Charts.
Figure 8. WIP Introduction Control Chart
Figure 8 charts the introduction of new Features as work-in-process. The calculation of the control limit on the chart is beyond the scope of this paper. This chart cannot be used in isolation as an introduction rate of 30 Features per day is not sustainable. It must be balanced with the WIP Inventory Control Chart [Figure 10] and the production rate plotted on Figure 2 as a trend line.
Figure 9. Project Scope Control Chart
Figure 9 charts the buffer usage by project dark matter. At the beginning of the project there are 185 Features in scope. If the Feature count were to fall below 170 then the manager may decide that it is safe to add some Features from the backlog which did not make the prioritization cut during the planning stage. Additional Features above 185 represent buffer usage and above 220 the project buffer is consumed in full. This chart cannot be used in isolation to calculate buffer usage, the production rate as plotted on Figure 2 as a trend line must also be used to validate the anticipated delivery date. [The observant and knoweldgeable reader will realize that this chart uses the specification limits and not the 3 sigma control limits. I am using this chart to protect the conformant quality - the on-time delivery of the project and therefore it is used as an emergency control indicator only
Figure 10. WIP Inventory Control Chart
The WIP Inventory Control Chart [Figure 10] shows us how much work is in progress. Again, the calculation of the control limits on the chart is out with the scope of this paper. However, the upper control limit indicates whether the aggregate complexity is dangerously high and potentially out of control as well as indicating whether or not the desired lead time of less than two weeks can be maintained. The lower control limit indicates that there is insufficient work-in-progress to maintain the desired production rate. The process is either stalling or starving from a lack of upstream material. A lagging trace of lead time can be maintained [Figure 11] and the data should remain within the control limits of 2 and 14 days providing the WIP Inventory was not permitted to become too large or too small [Figure 10].
Figure 11. Lead Time Control Chart
Monthly Operations Review
Data from CFDs can be used to identify the productivity rates or different elements in the whole process of software engineering. This data can be presented at an Operations Review. CFDs are intended for day-to-day tactical control use. Operations Review is about learning and organizational feedback. Learning provides input for strategic and operational investment decisions. It provides the material for good governance. Figure 12 shows a process diagram labeled with element capacities per month clearly identifying the current system constraint as System Test. According to the Theory of Constraints, maximum throughput (or productivity) is achieved by exploiting a constrained resource to the full and subordinating everything else in the system to the exploitation decision made. Continuous improvement is achieved by elevating the constraint thus removing it as the system capacity constrained resource (CCR). The effect is to move the constraint elsewhere whilst the system goes on to achieve a higher throughput.
The exploit decision made for this example is: all system testers have been relieved of all non-value-adding tasks. The subordination decisions made are: extra project managers have been assigned to complete those non-value-adding administrative tasks; system analysts have been assigned to write test plans for a future release, freeing up testers to work purely on current tests; and new material flow into the system has been restricted to 100 units per quarter, from a capacity of 100 units per month. The elevation decision made to remove the constraint is to hire 5 temporary staff to relieve the bottleneck.
Figure 12. Process Flow and Capacity
Operations Review should also report the status of all projects in a simplified rollup which provides accurate information properly aligned with the organizational goals. Figure 13 shows a buffer management parking lot diagram for a larger project with 7 Subject Areas. The colors on the chart indicate the overall buffer usage for the subject areas. This simple chart demonstrates clearly the software engineering organization’s ability to meet its promises with respect to wider programs and the dependent dates. The information is entirely objective and is derived from the rollup of fine-grained ideas for client-valued functionality, expressed as Features, laid out in a buffer protected Critical Chain schedule with an understanding of the intrinsic variability in the method. Figure 13 provides objective transparency of properly aligned engineering activities.
Figure 13. Buffer Management Parking Lot Chart
Executives at Operations Review are likely to focus their time on problem areas. In the example of Figure 13, Targeted Marketing Messages is shown as Critical status. A drill down of detail for Targeted Marketing Messages is shown in Figure 14. Only a few data points are required. The Subject Area is broken out into the feeding chains of Feature Sets and buffers for each feeding chain and the overall project buffer (treating the Subject Area as a sub-project in itself) is shown. This provides a finer granularity in to the area causing concern. In addition the number of units of inventory (Features) blocked are shown along with the recent trend, and the number of open issues in the issue log causing those blockages along with the recent trend.
Figure 14. Subject Area Drill Down
The open issues represent what is constraining the productivity and completion of the blocked Features. The Theory of Constraints teaches us to focus on the constraint. Hence, all management effort must be applied to eliminating the blocking issues in order to restore flow and bring the errant Subject Area back under control. If simply unblocking issues is not enough to recover the buffer then management may have to decide how to elevate in order to recover or to re-plan based on a new baseline for delivery.
Good Governance
Good governance is about making the right decisions to put the shareholders funds to the most appropriate use and to (hopefully) realize the best return on the investment. The typical approach to good governance is to use management accounting techniques to analyze alternatives and determine the best choice using a financial metric. Management accounting provides a normalized currency (dollars) for making choices. Management accounting is not about financial reporting or the overall health of a business, it is about doing the right thing – making the correct choice.
The Theory of Constraints inspired its own form of management accounting known as Throughput Accounting. Throughput accounting offers us a very simple model for analyzing complex systems. Figure 15 demonstrates how to allocate the parameters of T (Throughput), I (Investment) and OE (Operating Expense) for the complex system of software engineering.
Figure 15. Throughout Accounting for Software Engineering
Throughput is defined as revenue from sales (or value delivered) less direct costs. Direct costs are typically input costs such as part. However, in software engineering they are often downstream costs such as those associated with deployment. Throughput accounting offers two simple equations for calculating Net Profit and Return on Investment [Figure 16].
Net Profit = Throughput – Operating Expense
ROI = (Throughput – Operating Expense) / Investment
Figure 16. Throughput Accounting equations for Net Profit and Return on Investment
These numbers are not real financial numbers but management accounting metrics which help us to make decisions. The Net Profit figure tells us whether or not it would be sensible to proceed with the development of a software program. It tells us whether we will spend more developing it than we anticipate recovering from sales or value provided. The ROI figure tells us how good an opportunity use we are making of the marketing and upstream resources which conceive the ideas for new projects or programs.
We can relate the Throughput Accounting parameter allocation to Patterson’s Design Model of improving information as it applies to the process of software engineering [Figure 17].
Figure 17. TA allocation for the Patterson Model applied to software engineering
Upstream activities including ideation and analysis are assigned to investment. All architecture, design, coding and testing activities are assigned to operating expense. Throughput is delivered from working code deployed in the field and is the assessed as the value created less the direct costs of deployment including systems hardware for deployment.
From the Patterson model, we can realize that a local measurement which would be compliant with the overall goal would be the information discovered (or the uncertainty reduced) over the amount of money spent in each stage.
Figure 18. Patterson model showing Investment $$$ against uncertainty reduced
Local Optima = Reduction of Uncertainty / Investment in Ideas
Figure 19. Equation for Optimizing Investment
Figures 18 and 19 suggest that we should monitor how much return we get, in terms of reduced uncertainty, for the dollars we spend creating ideas, writing requirements and analyzing the problem domain.
Figure 20 shows how eXtreme Programming (XP) makes a tradeoff which assumes that very little benefit is gained from investing much effort upstream. The requirements are written on Story Cards and the development effort is started almost immediately. The on-site “customer” is supposed to provide the elaboration of detail as the development effort progresses with the construction of automated tests for the code which will implement the requirements on the Story Card.
Figure 20. Uncertainty reduction in XP
Figure 21 shows how Feature Driven Development varies in its approach by investing more upfront in the hope of significantly reducing uncertainty as a result of the domain modeling exercise.
Figure 21. Uncertainty reduction in FDD
From these models, we can see that the best management accounting metrics will be achieved by the process which optimizes the reduction of uncertainty and discovery of information leading to working code, using the shortest lead times.
Local Optima = Reduction of Uncertainty / Cost of Development
Figure 22. Equation for Optimizing Operating Expense
However, we cannot fully understand how to make the best choice over software engineering process without understanding the value of Throughput which can be generated. It may be true that newer fields of endeavor though riskier and more uncertain will produce greater Throughput. Hence, more may need to be invested in ideation, requirements and analysis and more may need to be spent on development but the overall financial results will be better.
Throughput
Throughput is difficult to define in advance. Marketing projections are at best a black art. However, market research and competitive strategy [Porter 1980] can be used to estimate the size of a market, the likely sales price and the market share achieved. Hence, estimates can be made. Michael McGrath [1995] provided a framework for market segmentation which allows us to make a fine grained assessment of the Features in a product definition which will appeal and enable particular market segments. Throughput Accounting would suggest that all Throughput generated from a sale should be assigned to the enabling differentiating Features which swung the purchase decision [Anderson 2003]. Figure 23 provides a simple example for an FDD knowledge base tool which segments the market by prospective user role and by price per client application for those prospective roles. Firstly, the Feature List is grouped into sets of Features which apply against the market segmentation as shown in Figure 23a. Figure 23b then maps these Feature groups against the role and price segmentation. Figure 23c maps the anticipated Throughput generated from each Feature group in each sector.
Figure 22a. Feature List grouped by market segment
Figure 22b. Feature groups by Market Segmentation
Figure 22c. Anticipated Throughput by Market Segment
Product Mix Prioritization
This anticipated Throughput data can be made to make product mix decisions and allocate resources in the most optimal way providing the system constraint is already identified.
Throughput Accounting [Corbett 1997] simply says that we must sort the product mix by the anticipated Throughput over the utilization of the current constraint. Figure 24 shows the data from Figure 23 mapped against the estimated utilization of the CCR – the System Test function.
Figure 24. Feature Group sorted by Throughput/CCR utilization
This data shows us that Feature Group 2 is most likely to generate the best return with Feature Group 4 delivering the least return. As resources are constrained and only so many features can be delivered in the next release, this data allows the product manager to make an informed decision not to enter the market segment for project managers with the next product release.
Conclusions
An agile approach to software engineering management is a wholly different approach to the traditional methods employed in the SDLC and PMI Critical Path project management approaches.
Software engineering should be viewed as a value chain where ideas are turned into working code using Patterson’s design process model of information discovery and uncertainty reduction.
Fine-grained ideas for client-valued functionality can be tracked through the value chain as they go through transformational steps towards fully working software. By aligning the day-to-day activities of software engineers with the anticipated value contained in ideas for client-valued functionality, management aligns the use of stockholders funds with their best interest in generating a return on investment.
Tracking fine-grained functionality through its transformational steps provides a simple and relevant metric for transparently reporting software engineering activity. This same metric can be self-generating through the use of instrumented configuration management systems, and provides a view into the work-in-process inventory in the system of software engineering. It is already well understood that inventory provides a leading, predictive indicator of process performance.
Inventory levels can be monitored by plotting the transformational progress of ideas for client-valued functionality on a cumulative flow diagram. Derivative data from the cumulative flow diagram can be used to monitor the production rate and the flow of new ideas into the system. It can also be used to identify system bottlenecks through the accumulation of inventory at any one step in the process.
A probabilistic approach to project management is required which understands the variability inherent in software engineering. Critical Chain provides such an approach. Critical Chain buffer monitoring can be used to provide an honest and fully aligned reporting scheme for senior executives.
The Theory of Constraints’ Throughput Accounting method of management accounting can be used for the Patterson design process model as applied to software engineering. This provides a mechanism for making good quality decisions designed to make optimal use of the stockholders’ funds.
The use of constraint monitoring and the application of the Theory of Constraints allows for the development of a system of continuous improvement with a focus on increased productivity relative to optimal use of stockholders funds applied to the investment in improvement.
The use of the Wheeler matrix and the monitoring of the process of software engineering against variation and conformant quality ultimately leads to opportunity to continually redefine conformant quality in a narrower band and use quality as a competitive weapon. The FDD method contains elements which are compatible with the DMAIC, DMADV and Global 8D methods in Six Sigma.
Together, the application of Patterson’s Design Process Model, Reinertsen’s observations on DIP (Design-in-Process) inventory and use of cumulative flow diagrams, the application of the Theory of Constraints’ Drum-Buffer-Rope solution for inventory flow, Critical Chain for probabilistic project scheduling and Throughput Accounting for normalized management decision making, provide the necessary and sufficient combination of control mechanisms to simplify the complex system of software engineering and deliver transparent reporting of progress, properly aligned tasks for engineers, improving productivity, and the opportunity for good governance of all software engineering activities.
References
[Anderson 2003] Anderson, David J., Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, Prentice Hall, Upper Saddle River, NJ, 2003
[Corbett 1997] Corbett, Thomas, Throughput Accounting, North River Press, Great Barrington, MA 1997
[De Marco 1999] De Marco, Tom & Timothy Lister, Peopleware – Productive Projects and Teams, 2nd edition, Dorset House, New York, NY, 1999
[Goldratt 1984] Goldratt, Eliyahu M., The Goal, The North River Press, Great Barrington, MA 1984
[Goldratt 1990] Goldratt, Eliyahu M., What is this thing called The Theory of Constraints, North River Press, 1990
[Goldratt 1997] Goldratt, Eliyahu M., Critical Chain, North River Press, 1997
[Leach 2000] Leach, Lawrence, Critical Chain Project Management, Artech House, 2000
[McGrath 1995] McGrath, Michael E., Product Strategies for High-Technology Companies – How to achieve growth, competitive advantage and increased profits, McGraw Hill, New York, NY 1995
[Palmer 2002] Palmer, Stephen R, and John M. Felsing, A Practical Guide to Feature Driven Development, Prentice Hall PTR, Upper Saddle River, NJ 2002
[Patterson 1993] Patterson, Marvin, Accelerating Innovation, Van Nostrand Reinhold, New York, NY 1993
[Porter 1980] Porter, Michael E., Competitive Strategy – Techniques for Analyzing Industries and Competitors, Free Press, New York, NY 1980
[Poppendieck 2003] Poppendieck, Mary and Tom Poppendieck, Lean Software Development – an agile toolkit, Addison Wesley, New York, NY 2003
[Reinertsen 1997] Reinertsen, Donald G., Managing the Design Factory – A Product Developer’s Toolkit, Free Press, New York, NY 1997
[Senge 1990] Senge, Peter M., The Fifth Discipline – The Art and Practice of the Learning Organization, Currency Doubleday, New York, NY 1990
[Smith 1776] Smith, Adam, An inquiry into the wealth and causes of The Wealth of Nations, reprinted by Modern Library, 1994
[Taylor 1911] Taylor, Frederick Winslow, The Principles of Scientific Management, reprinted by Dover Publications, 1998
[Weinberg 1992] Weinberg, Gerald M., Quality Software Management Volume 1: Systems Thinking, Dorset House, New York, NY 1992
[Womack 1991] Womack, James P., Daniel T. Jones & Daniel Roos, The Machine that Changed the World, Harper Perennial, 1991
[Womack 1996] Womack, James P., Daniel T. Jones, Lean Thinking – Banish Waste and Create Wealth in Your Corporation, Simon & Schuster, 1996
[Wheeler 1992] Wheeler, Donald J., and David S. Chambers, An Introduction to Statistical Process Control, SPC Pr
Download the Paper [PDF format 2,703K]
Download the Slides [PDF format 682K]