Library of Congress Cataloging-in-Publication Data

Anderson, David J. (David James)Agile management for software engineering / David Anderson

p. cmIncludes indexISBN 0-13-142460-2.1. Software engineering. 2. Computer software--Development--Management. I. Title

QA76.75 .A48 2003005.1--dc22

2003017798

Editorial/production supervision: Carlisle Publishers ServicesCover art: Jan VossCover design director: Jerry VottaArt director: Gail Cocker-BoguszInterior design: Meg Van ArsdaleManufacturing manager: Alexis R. Heydt-LongManufacturing buyer: Maura ZaldivarExecutive editor: Paul PetraliaEditorial assistant: Michelle VincentiMarketing manager: Chris GuzikowskiFull-service production manager: Anne R. Garcia

© 2004 by Pearson Education, Inc.Publishing as Prentice Hall Professional Technical ReferenceUpper Saddle River, New Jersey 07458

Prentice Hall PTR offers excellent discounts on this book when ordered in quantity for bulk purchases orspecial sales. For more information, please contact: U.S. Corporate and Government Sales, 1-800-382-3419,corpsales@pearsontechgroup.com. For sales outside of the U.S., please contact: International Sales,1-317-581-3793, international@pearsontechgroup.com.

Company and product names mentioned herein are the trademarks or registered trademarks of their respectiveowners.

All rights reserved. No part of this book may be reproduced, in any form or by any means, without permissionin writing from the publisher.

Pearson Education LTD.Pearson Education Australia PTY, LimitedPearson Education Singapore, Pte. Ltd.Pearson Education North Asia Ltd.Pearson Education Canada, Ltd.Pearson Educación de Mexico, S.A. de C.V.Pearson Education–JapanPearson Education Malaysia, Pte. Ltd.

Printing10th September 2009

Text printed in the United States on recycled paper at Hamilton in Castleton, New York.

ISBN 0-13-142460-2

xxi

Foreword

It is so good to finally have a book targeted at the software industry thatchallenges some of the basic business assumptions behind software engi-

neering, and particularly those behind managing software organizations. Atthe time these words are written, the software business is facing huge diffi-culties worldwide. I hope that these difficulties also generate a willingness tolook afresh at the business and to have the courage to contemplate changes.Other industries, particularly in manufacturing, went through such conceptu-al changes in their business processes during the 1980s and the 1990s. It iscertainly not easy, but as I’ve personally experienced, it is highly desirable.

In 1985 I managed my own software company in Israel and was quite proudwith my new package for certified public accountants. But, even though my pack-age competed very nicely in the market, I noticed an on-going business prob-lem: More and more development was needed to keep the package alive. In sucha case, how do I justify the on-going investment? Eventually, I was not sure thata small software company, focused on a specific market niche, could be a goodbusiness—even when the product itself was enthusiastically accepted by themarket. I felt that even though I already had my MBA, I needed a better per-spective to understand the business.

Then I met Dr. Eli Goldratt.

I had heard a lot about Dr. Goldratt’s international software company,Creative Output, Inc., which was seen as much more than just an excellentand innovative software company. It challenged some of the most sacrednorms of business, such as the concept of product cost. I could not under-stand how anyone could challenge the basic concept that a unit of a producthas a certain cost associated with it. I was intrigued enough to be open to anoffer: Join Creative Output in order to develop a video game for managers thatwould deliver some new managerial ideas. At the time, computerized gameswere focused on fast fingers and perfect coordination. They were certainly notsomething of interest to adults. How could a computer game be readilyaccepted by grown-up managers and deliver new managerial ideas?

This was the start of a mental voyage into a new management philoso-phy that does not lose its grip on reality. I turned myself into a managementconsultant with a focus on improving whatever is the particular goal of theorganization. Software became an important supporting tool, but not thefocus of the change efforts.

The relevance of the Theory of Constraints (TOC) to the software indus-try is twofold:

1. Vastly improving the flow of new products to the market.

2. Determining the real value of a proposed project, or even justa feature, to the final user. The underlying assumption is thatif we know the real value to the user, it is possible to developthe right marketing and sales approach to materialize thevalue to the user and to the software organization.

David Anderson focuses mainly on the first aspect in this book, whichincludes looking at the business case and ensuring the ability to make it hap-pen. Software organizations can definitely be improved with the help of thenew generic managerial insights that have already changed traditional west-ern industries. David does a great job in bringing together the generic mana-gerial ideas and rationale and combining them with software-focusedapproaches to come up with a coherent approach on how to improve thebusiness.

Read this book carefully with the following objective: Learn how to makemore with less. Don’t accept every claim David raises just because he says itis so. If you truly want to make more with less, you need to be able to inter-nalize the claim. All I ask is you give it a chance. Dedicate time in order torethink your environment, and then see for yourself what to do. Overcominginertia is the biggest challenge of any really good manager in any organization.Of course, rushing to implement new fads can be even worse. Keeping an openmind and confronting new ideas that invalidate basic assumptions are what Isuggest you strive for. This book is for you to struggle with. It is not trivial, andit is not a fad. If you like what you do now, it should be your responsibility tocheck out new ideas that might yield huge improvements.

Here are some brief insights regarding the assessment of the value to apotential customer of a new feature, particularly to a new software package.

A new Feature can bring value to the user only if it eliminates, orvastly reduces, an existing limitation. The amount of the value depends onthe limitation removed—not on the sophistication of the feature itself. Let ustake a simple example. At a certain time in the history of word processors,somebody had an idea: Why not add a spell checker to the package?

What is the value of the spell check we now have as a routine feature?What limitation does it eliminate or reduce? For people with a very goodknowledge of the language, spelling mistakes are caused by writing too fast.So, without a spell checker, those people need to read carefully what they justwrote. People who are not in full command of the language (for example, me,as an Israeli) need to look at the dictionary very often, which is quite timeconsuming.

This need leads us to recognize two additional insights.

People developed some rules to help them overcome the limitation.People who used word processors had to go over whatever they just wrotebefore sending the document to others. People without good command ofthe language needed to be supported by a dictionary.

Foreword

xxii

Once the limitation is vastly reduced, people should replace the oldrules with new ones that take full advantage of the removal of the limita-tion. If this does not happen, then there is no added value to the Feature.

Now we can see whether adding a spell checker to an existing wordprocessor brings value. Suppose you have perfect command in the lan-guage, would you now refrain from carefully reading your recent documentbefore sending it away? Spelling mistakes are hardly the main reason to goover any document that I want other people to read. So, for people withperfect knowledge, the spell checker offers no real value. But, for me as aperson in good command of Hebrew, but not good enough in English,spelling mistakes in English are a nuisance. But, could I really avoid themjust by the use of a spell checker? As long as the spell checker does notsuggest how to write the word correctly—the limitation is only marginallyreduced and thus not much value is produced. This means that if we wantto generate significant value for the specific user group that has not mas-tered the language, we need to add good suggestions of what should bewritten instead.

In this simplified example, we already see the need to check the behav-ior rules both before the limitation is eliminated and after. Is it always clearwhat the new behavior rules should be? Assuming the user is well aware ofwhat the new rules should be is a very common trap for too many softwarefeatures.

Suppose that a new Feature is added to a sales-graph display module inwhich the trends shown by the graph are analyzed for statistical significance.The limitation is lack of knowledge on whether market demand is really up ordown or just part of the normal statistical fluctuations. The current behaviorof the management is: If sales are up, the sales agents are complimented andget appropriate bonus; if sales are down, there are no bonuses and some hardtalk from management.

What should the new management rules be once management knowswhether the rise in sales is significant? I’m afraid that in the vast majority ofthe cases the behavior will be exactly the same. Hence, the newly addedFeature will not add value to the customer, even though some customersmight ask for it and even exert a lot of pressure to have the Feature devel-oped. Eventually, the value to the software company of developing theFeature will be negative.

Of course, for a good managerial consultant assisting in the formationof better decision processes, a specific Feature can bring immense valueboth to the consultant and the client. In this case, a strategic partnershipbetween the consultant and the software company can be a win-win for all,including the client.

Improving the flow of the Features that truly bring value to the customerand also have a good chance of generating revenues for the software organi-zation is what this unique book is all about. The Agile Manifesto principle of“Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software” is fully in line with the Theory of Constraint’sobjectives. To be more precise, TOC strives to generate more of the organiza-tion’s goal. But, in order to do so, the organization has to generate more value

Foreword

xxiii

to its customers. The means of early and continuous delivery of software thattruly generates value should assist both the software organization and itsclients in achieving more of their respective goals.

Please bear in mind that improvement has only one criterion: Achievingmore of the goal. The path to truly improving the performance of your soft-ware organization may well start with this book.

Eli Schragenheim

Foreword

xxiv

Introduction

“Poor management can increase software costs morerapidly than any other factor.”

Barry Boehmi

A s Barry Boehm points out, bad management costs money [1981]. Thesedays it also costs jobs. Senior executives, perplexed by the spiraling

costs of software development and depressed by poor results, poor quality,poor service, and lack of transparency are simply shrugging their shouldersand saying, “if the only way this can be done is badly, then let me do it badlyat a fraction of the cost.” The result is a switch to offshore development andlayoffs. With the state of the economy in 2003, what was a trickle hasbecome a positive trend. If the trend isn’t to become a flood, managementin the information technology business needs to get better. Software devel-opment has to cost less and produce better results—more reliably, withbetter customer service, and more transparency. This book will teach theAgile manager how to achieve that.

Building software costs a lot of money because it is labor intensive knowl-edge work.

Software engineers and their colleagues in project management andrelated functions are very well paid. It’s a basic supply versus demand prob-lem. Throughout most of my life, demand for IT workers has exceeded supply.The rates of pay have risen accordingly. Most software engineers under theage of 40 earn more than their peers who entered traditional professions suchas medicine, law or accountancy. In many American firms, software engineer-ing pays better than marketing.

Recently, with the global economic downturn, large corporations and manysmaller ones are focused on trimming costs to improve profits or reduce losses.The high dollar line item for IT is under pressure. CIOs are having their budgetscut. The result is that jobs are moving offshore to outsource firms in Asia,Australia, and Eastern Europe. Knowledge work is moving out of rich countriesand into poorer countries. Typically, an Indian outsource supplier can offer alabor rate of 25% of the rate for an equivalent U.S. software developer.

xxv

Why AgileManagement?

The EconomicImperative

i[Boehm 1981] Software Engineering Economics

If software knowledge work is to remain in the rich, developed countriesof the world and software engineers in America, Europe, and Japan are tomaintain the high standard of living to which they have become accustomed,they must improve their competitiveness. There is a global market for soft-ware development, and the rise of communications systems such as theInternet, have made it all too easy to shrink the time and distance between acustomer in North America and a vendor in India or China.

Jobs are at stake! Just as western manufacturing was threatened by therise of Asia in the latter half of the 20th century, so too is the knowledge work-er industry threatened by the rise of a well-educated, eager workforce who cando the same work for between one tenth and one quarter of the cost.

The answer isn’t that software developers must work harder if they wantto keep their jobs. Software engineers aren’t the problem. The answer is thatmanagement techniques must improve and working practices must change inorder to deliver more value, more often, in order to improve competitiveness.

This is a book about software engineering management. It is also a bookabout business. It is a book about managing software engineering for the pur-pose of being successful at business. It will offer proof that Agile softwaredevelopment methods are better for business.

The information technology industry hasn’t been good at managing soft-ware engineering and hasn’t shown an aptitude for management and processcontrol. As a result, information technology businesses are often run by seat-of-the-pants intuition and rough approximations. It is common, to the pointof being accepted as industry standard practice, for information technologyprojects rarely to follow the plan, to be late and over budget and fail to deliv-er what was promised.

Software engineering management is traditionally a poorly practiced pro-fession. This may be because it is poorly (or rarely) taught. Only recently hasmy local college, the University of Washington, begun offering an MBA pro-gram in high technology management. Such programs are rare. As a result,there is little management expertise in the industry.

However, many techniques do exist that can improve the competitive-ness of software development businesses. These techniques have beenproven in other industries. The challenge has been figuring out how to applythem to software development. Techniques such as the Theory of Constraints[Goldratt 1990a], Lean Production [Womack 1991], Systems Thinking [Senge1990], and new ideas evolving out of the recent science of Complex AdaptiveSystems are providing insights that unleash the latent ability of knowledgeworker talent.

The secret to economically viable software engineering is new workingpractices based on new management science. The Agile manager must con-struct an Agile learning organization of empowered knowledge workers. Whenthis is achieved the results will be dramatic. Improvements of 4 times are eas-ily achieved. 10 times is definitely possible. Imagine if your software engi-neering organization could do 5 times as much work in half the time itcurrently takes. What would it mean for you, your job, and your organization?

The Thesisfor Agile

Management

Introduction

xxvi

Knowledge work isn’t like manufacturing. Stamping out car bodies can beperformed with a high degree of certainty. It is dependable to within a verylow tolerance. Failures and errors are rare. The time to stamp two car bodiesis almost precisely twice the time to stamp a single car body. The time tostamp 100 bodies is probably precisely derived from the time to stamp a sin-gle car body multiplied by 100. Manufacturing is in many ways predictable,linear, and, in the case of chemical processes, defined by scientific rules.

Knowledge work is neither linear nor defined. So it isn’t like manufactur-ing. The assumption has been that because it isn’t like manufacturing andisn’t predictable and linear, it just can’t be managed the same way. In fact,attempts to bring traditional management to software engineering processeshave tended to fail. Software projects rarely if ever run to plan, and estimat-ing is generally a black art with the resultant estimates often a complete fic-tion. Software development, from the perspective of the boardroom, has beenout of control.

This book will show that dismissing software engineering as an uncon-trollable process is wrong. It can be managed like other parts of a business.The secret is to manage the right things and to do so with transparency. Justbecause software engineering has greater uncertainty associated with it thanmanufacturing production does not mean that management methods areinvalid. It simply means that those methods must accommodate greateruncertainty. The Theory of Constraints teaches managers how to buffer foruncertainty and this book will explain how to apply that technique to softwaredevelopment. It is important that value chain partners, management, andshareholders understand the correct model for managing software develop-ment, a model that accommodates uncertainty, and learn to trust the tech-niques of the Agile manager.

The Agile manager’s new work becomes a study in setting the governingrules for controlling the system of software production. The Agile managerneeds to learn what to track, how to track it, how to interpret the results, andwhat to report to senior management. This book explains what, why, and howto do this.

Some high technology workers on the west coast of the United States are giv-ing up the profession and changing careers. All around the world, high techworkers are disillusioned. They are beginning to realize that a job in hightechnology is not worth sacrificing family life, social life, or health. They arerealizing that their hourly rate doesn’t look so good, considering all theunpaid overtime they are expected to work. They are realizing that there mustbe more to life.

One former colleague, from my time in Singapore, recently trained as anartist and photographer. Another, with whom I worked in Kansas City, quit thebusiness and moved to Paris, France, where he works in the non-profit sector.Another colleague recently resigned in order to start an auto-tuning business.Yet other colleagues, who work as contractors, are only prepared to work parttime. One prefers to work in a shoe store, and another does flower arranging.I hear similar anecdotes from people I meet all over the industry. What ishappening?

AcceptUncertainty,Manage withTransparency

A Trend ofFrustration

Introduction

xxvii

IT workers turn up for work for four reasons: the cause (the vision andleadership of the organization), the love of technology (usually a specificchoice in which an almost religious fervor is aroused), the money (and it isusually pretty good), and the boss (people really do work for people). Let’sconsider these in turn.

The cause and the technology can often be grouped together. Theyinclude the mission of the business, the vision of the future, the technologybeing used, and the industry into which all of this is being deployed. Thereare IT workers who will simply never work in the defense business, for exam-ple. Creating a great cause that will draw people to it is a matter for greatleadership. There has been much written about leadership in recent years.Perhaps there is a yet-to-be-written great book about IT industry leadershipbut teaching leadership is not within the scope of this book.

The money is important. IT workers are in demand. Demand exceeds sup-ply. Even in hard times, demand for IT workers remains strong. Often a reces-sion strengthens demand because automated systems can replace otherworkers and reduce cost. Consider the recent trend in automated machinesfor airline check-in, for example.

The boss is very much the scope of this book. If the boss doesn’t get it, thestaff will get disillusioned and leave. High staff turnover in IT businesses is usu-ally an indication that the management “doesn’t get it.” Management is impor-tant. People like to work in well managed, properly organized environments.They like to have clear objectives and an environment in which to do great work.

This book will give IT industry bosses a new set of tools for managing. Itwill show them how to assess the IT parts of their businesses, as they wouldany other part of the business. It will show how to demonstrate whether ornot IT delivers true value-add and produces a suitable return on investment.

Running software engineering as a proper business actually produces effectsthat result in more optimal use of resources, more efficient production of code,and a better creative and professional environment for the staff. When the bossreally “gets it,” the staff knows it and like it. The key to low staff turnover and highperformance from a software development organization is better management.

Recently, there has been a rebellion in the industry against the growing tideof poor performances, long lead times, poor quality, disappointed customers,and frustrated developers. It is a rebellion against poor management. A pas-sionate body of software developers has declared that there must be a betterway—delivering software should be more predictable. These passionate peo-ple espouse a number of new software development methods, which theyclaim will enable faster, cheaper, better software development with on-time,on-budget delivery of the agreed scope. These new methods are known col-lectively as Agile methods.

The word “agile” implies that something is flexible and responsive and ina Darwinian sense has an innate ability to cope with change. An agile speciesis said to be “genetically fit.” By implication, Agile software developmentmethods should be able to survive in an atmosphere of constant change andemerge with success.

The AgileManifesto

Introduction

xxviii

The accepted definition of Agile methods was outlined in February 2001at a summit meeting of software process methodologists which resulted in theManifesto for Agile Software Development.ii It was created by a group of 17professionals who were noted for what, at the time, were referred to as “light-weight” methods. Lightweight methods started with Rapid ApplicationDevelopment (RAD). The RAD approach sought to time-box software releasesto strict delivery dates, subordinating everything else in the project, includingbudget, scope, and staffing levels to achieve the delivery date. The term “rapid”came from the suggested nature of the time-boxes—much more frequent thantraditional software development, that is, 2 weeks to 3 months.

Agile methods are mostly derived from the lightweight approach of RAD.They add extra dimensions, primarily the recognition that software develop-ment is a human activity and must be managed as such.

Manifesto for Agile Software Development

We are uncovering better ways of developingsoftware by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

Kent Beck, James Grenning, Robert C. Martin, Mike Beedle, JimHighsmith, Steve Mellor, Arie Van Bennekum, Andrew Hunt, KenSchwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward

Cunningham, John Kern, Dave Thomas, Martin Fowler and Brian Marick

© 2001, the above authorsthis declaration may be freely copied in any form,

but only in its entirety through this notice.

The Agile Manifesto, as it has become known, is a very simple and con-cise declaration that seeks to turn the traditional view of software develop-ment on its head. The manifesto is based on 12 principlesiii:

Our highest priority is to satisfy the customer through early and continuous delivery of

valuable software.

iihttp://www.agilemanifesto.org/.iiihttp://www.agilemanifesto.org/principles.html. Kent Beck, James Grenning, Robert C.Martin, Mike Beedle, Jim Highsmith, Steve Mellor, Arie Van Bennekum, Andrew Hunt, KenSchwaber, Alistair Cockburn, Ron Jeffries, Jeff Sutherland, Ward Cunningham, John Kern,Dave Thomas, Martin Fowler, and Brian Marick.

Introduction

xxix

Welcome changing requirements, even late in development. Agile processes harness change

for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a develop-

ment team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users

should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity—the art of maximizing the amount of work not done—is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and

adjusts its behavior accordingly.

There are a number of Agile methods. In Section 2, this book looksclosely at three of them—Extreme Programming (XP), Feature DrivenDevelopment (FDD), and Scrum. Though other Agile methods are notexplored, the book will provide the basic guidelines and metrics for mak-ing an appropriate assessment of each in comparison to more traditionalsoftware development methods.

Agile methods propose some unusual working practices. Extreme Programming,as its name suggests, has some of the more radical. They often go by names thatsound as if they belong in the skateboard park or amongst the off-piste snow-boarding community. The strange language and the strange practices scaremanagement in large companies. Are they ready to stake their careers, reputa-tions and fat bonuses on pair programming and stacks of filing cards?

Agile methods introduce scary counter intuitive working practices. Ifmanagerial fears are to be overcome, it is necessary to provide managementmethods that allay those fears. This requires methods that report believableand familiar statistics and have meaning to the business. It is necessary todemonstrate the economic advantages and focus on real business benefits.Software development is about making more profit, not about making greatcode. By leading with the financial arguments, senior managers in large com-panies can gain confidence that the expensive knowledge workers understandthe true goal. This book will show how to mature a software engineeringorganization to the point where it can report believable financial metrics. Itwill also show what those metrics should be and how to calculate them.

The Problemwith Agile

Methods

Introduction

xxx

Agile methods promise a lot, but where is the proof? Agile methodologistswill reply that, “the proof is in the pudding.” In other words, give it a try andfind out for yourself. These claims have been heard before. Who can recall4GL (so-called “fourth generation languages”) that promised to eliminatedevelopers and allow ordinary workers to create labor saving tools for them-selves? Or perhaps you were sucked into the world of visual software assem-bly from components? Did the arrival of Visual Basic really eliminatedevelopers? The IT world has been full of promises. Why should Agile meth-ods be any different?

Are Agile methods a genuine trend in changing working practices or arethey just another fad that lets software people “goof off” at work? This bookwill show that Agile methods echo the techniques of Lean Production and theTheory of Constraints which revolutionized manufacturing industry.

Agile software development is really about a change in working practicesand a change in management style. Agile methods understand what man-agement truly is. They understand that management is more than economicsand engineering, that it is very much about people. “Rightly understood,management is a liberal art, drawing freely from the disciplines that help usmake sense of ourselves and our world. That’s ultimately why it is worthdoing” [Magretta 2002, p.3]. Because of this basis in existing experience, Ifirmly believe that the Agile approach is a genuine trend, a change in workingpractices and paradigm shift in how software is produced. It is not a fad.

In order to adopt Agile methods in a large corporation, it is not enough to gobefore the board and say, “Gee, people say this works. Why don’t we give it atry?” The CIO is likely to be a pragmatist, not prone to early adoption or risktaking. It will be necessary to argue a business case based on hard numbersindicating better profitability and higher return on investment. Doing so isthe only way to make Agile methods look attractive and to fight against theshort-term thinking that is driving decisions to outsource software engineer-ing offshore.

This book will arm the Agile manager with the material to make a busi-ness case for agility. Agile methods can be justified on improved value-addedand ROI. This book will teach the Agile manager to manage up and lead witha financial argument.

A framework for scientifically measuring and assessing Agile methods ispresented. The metrics involved are used to determine the level of added valueand the received return on investment. Much of the work that made this possi-ble was developed by Eli Goldratt and his colleagues. It is a body of knowledgeknown as Throughput Accounting [Corbett 1997]. Throughput Accounting,based on the applications of the Theory of Constraints to manufacturing pro-duction, is used as the basis for the financial arguments presented.

AgileMethods—A Fad or aTrend?

The BusinessBenefit

Introduction

xxxi

While the West during the 1970s and 1980s was focused on increasedautomation through the use of robots on the assembly line, the Japanese pro-duced far better results through management techniques that changed work-ing practices. These working practices originated at Toyota and are known asthe Toyota Production System or Kanban Approach.

The technology industry has for the last 30 years, like western manufac-turing, also been focused on technology solutions. There have been third andfourth generation languages, modeling and abstraction tools, automatedintegrated development environments, and automated testing tools. To someextent, the Agile community rejects this ever increasing technology approachand instead embraces new management techniques and changes to workingpractices. In this respect, Agile methods resemble the principles first advo-cated by Toyota and now known in the West as Lean Production.

The techniques of Lean Production created an economic improvement oftwenty to fifty fold during the second half of the 20th century. For example,Womack and colleagues [Womack 1991] report that in one recent year Toyotabuilt half as many cars as General Motors using less than 5% of the people.In other words, Lean Production at Toyota had produced a ten fold improve-ment over its American mass production competitor. Some Agilists arereporting four fold economic improvements [Highsmith 2002; Schwaber2002]. This is equivalent to the improvements made in automobile manufac-turing in Japan in the earlier part of that half century—for example, those atMazda between the 1960s and 1980 when productivity was improved by fourfold. During the most recent twenty years, some of these manufacturers havegone on to make improvements of five times or greater. This produced acumulative economic improvement of twenty times or more. It is preciselythese types of gains that created the Asian economic miracle of the latter20th century and provided vast wealth across the globe.

If Agile software development can provide a four fold improvement with-in 9 months, why would a company outsource to an Indian supplier thatpromises a four fold cost reduction over 3 to 4 years?

The software industry now employs over 30 million people worldwideiv

and can list the world’s richest company, Microsoft, amongst its number.What if it were possible to create another economic miracle? What if softwaredevelopment resembled the manufacturing efficiency of 1925? It is just pos-sible that Agile methods represent the beginning of an understanding of howto build software better, faster, and cheaper. Is it just possible that there is alatent economic improvement in the order of 95% waiting to be unleashed?Agile methods are a step down the road to a leaner knowledge worker indus-try. They really do produce financial benefits, and this book will demonstratehow to calculate them.

Toward aSoftware

EconomicMiracle

ivEstimates taken from figures by Gartner Group and IBC suggest that there are around 15 mil-lion software developers. It is reasonable to assume that those employed in other related func-tions, such as project, program, and product management, will account for 15 million more.

Introduction

xxxii

“Most management books are only for managers. This one is for everyone—for the simple reason that, today, all of us live in a world of management’smaking. Whether we realize it or not, every one of us stakes our well-being onthe performance of management,”v said Joan Magretta introducing her book“What Management Is” [2002, p.2]. As Tom DeMarco observed in his book“Slack,”vi the Dilbertsvii of the world have abdicated responsibility. It suitsthem to blame the manager. Dilbert fails to see it as his duty to help his man-ager be more effective. Management is a task that concerns everyone involvedin a business from the stockholders to the most junior of employees. Hence,this book is intended for a wide audience—an audience of anyone who careswhether or not a software business is well run.

The text is intended for anyone who is interested in changing the workingpractices of software development to make them more effective and more com-petitive. The book is primarily aimed at all levels of management in all software-related disciplines and those who aspire to senior individual contributor or linemanager positions in the foreseeable future. It should also appeal to Mastersdegree and MBA students looking for a management career in a software-relatedindustry. Every CEO, CFO, COO, and CIO who runs a business with significantexpenditures on software development activity needs to understand the newparadigm and theory presented in Section 1. Lou Gerstner, writing in his IBMmemoir pointed out that cultural change must be led from the top if it is to beeffective [Gerstner 2002]. If change is to be led from the top, the boss mustadopt the correct mental model of Agile development practices in order to framedecisions and understand the counterintuitive activity happening beneath.

This book defines 4 basic management roles and describes a set of practicesfor each role. Those roles are development manager, program manager, proj-ect manager, and product manager. Each is described in Chapter 8, “The AgileManager’s New Work.” Specific details for the development manager’s role aredefined in Chapters 5 and 9. The program manager’s role is defined inChapter 10. The project manager’s role is defined in Chapter 7. The productmanager’s role is defined in Chapter 16.

The thesis of the book is that the development manager is responsible forrunning an on-going system of software production. This must be managed withmetrics based on fine grained units of production activity. However, programsand projects must be measured at a coarse grained level that reduces the uncer-tainty through aggregation of fine grained tasks. How to buffer against variabil-ity is explained in Chapter 4. The product manager must define the groupings offine grained functionality which have meaning as valuable deliverables, that is,the coarse grained items to be tracked by the program and project manager.

Together, all 4 roles interact to define a 2-tiered management systemthat sets the governing rules for the system, but allows highly delegated,

v[Magretta 2002] What Management Is, page 2.vi[Demarco 2001] SlackviiDilbert is a registered trademark of United Feature Syndicate. Dilbert, a cartoon charactercreated by Scott Adams, suffers under a pointy haired boss who just doesn’t get it!

Who ShouldRead ThisBook

A Thesisfor NewManagementPractices

Introduction

xxxiii

self-organization within. Successful Agile management requires a highly del-egated system of empowered knowledge workers. The essence of Agile man-agement is self-organizing production, framed within the planned assemblyof valuable components, and delivered frequently to generate a the requiredROI for the business.

Chapter 11 introduces the notion that Agile methods can mature in an organ-ization as it learns to use them better. This book leads with the financial met-rics. It focuses on the true goals of a business and then examines howmanagement must organize and report the day-to-day workings of the soft-ware production system in order to deliver the desired financial results. Thisapproach has been taken to demonstrate the compelling reason for switchingto Agile software development.

In practice, the approach to delivering a failure-tolerant, agile, learningorganization will happen inside-out. The working practices will come first,then the traceability, then the metrics, then learning, and eventually the finan-cial metrics and results. The Agile Maturity Model describes this progression.

Section 1 is intended as general reading for anyone interested in running a soft-ware development business for better results. It is suitable reading for all lev-els of management from team lead developers to CIOs, CEOs, CFOs, and GMs.Section 1 explains Agile management, its practices and theory. It explains howto apply the Theory of Constraints and Lean Production methods to softwareengineering as a general practice. For many readers Section 1 will be sufficient.

Section 2 is intended for readers who need to manage the change to Agilesoftware development in their organization and for those who need to under-stand why they are making a change and how to implement what they arechanging to. Chapters 19 and 20 give an outline of traditional software devel-opment methods and will help an agile manager explain the current realityand create a baseline from which to measure improvement. The remainder ofSection 2 surveys a subset of Agile software development methods. This sur-vey is not meant to be exhaustive. It shows, by example, how to relate specif-ic Agile methods to the theory presented in Section 1. Chapters 21 through 30lay out possible future realities for an Agile software development organiza-tion and demonstrate how to measure them to show an economic improve-ment. FDD, XP, Scrum, and RAD are compared against the theory from Section1. The emphasis is on explaining these methods rather than comparing themagainst each other. Relative comparisons are left for Section 3.

Section 3 is for those who need to choose one method over another andthose who seek to understand Agile methods and develop the future of Agilesoftware development management. It seeks to understand the similaritiesand differences and the varying foci of currently available Agile methods. Theapplicability of these methods is considered against their appropriateness fordifferent types, sizes, and scales of software projects. Section 3 is intendedprimarily for Agile methodologists and those who wish to further the debateabout the future of Agile software development.

An AgileMaturity

Model

How to ReadThis Book

Introduction

xxxiv

TOC in Software Production

The Theory of Constraints can be explained with a simple five-step processthat needs little explanation.

1. Identify the System Constraint.

2. Decide how best to exploit the System Constraint.

3. Subordinate everything else to the decision in step 2.

4. Elevate the Constraint.

5. If steps 1 through 4 have created a new constraint, return to step 2.

TOC is founded on the notion that a value chain is only as strong as itsweakest link. The conjecture is that there is only one weakest link at any giventime. This weakest link is known as the constraint. In a process or system thattakes input and produces output under some control mechanism, the con-straint is described as the capacity constrained resource (CCR).1 In otherwords, the value chain is a chain of processes or systems that add value to araw material and turn it into a finished product. The rate of production of thefinished product is constrained by the rate of production of the slowest (orweakest) element in the value chain.

If TOC is to be used to improve a system, constraints must be identified, oneby one. Physical constraints are also known as bottlenecks. Hence, identify-ing bottlenecks is a good place to start looking for the current constraint. It isgenerally assumed that there is only one global system constraint at anygiven time. There may be several bottlenecks, but only one will be constrain-ing the overall Throughput.

Figure 3–1 shows a software production system that is constrained by thecapacity of System Test, which is only capable of processing 30 units of produc-tion per month. The capacity of Acceptance Test at 80 units per month is irrele-vant. At most, only 30 units will be passed to Acceptance Test every month.

Once the constraint has been identified, a decision must be made onhow to minimize its constraining ability on the system. The utilization or

29

chapter

TOC’s FiveBasic Steps

Identify andExploitConstraints

1The term CCR is an abstraction. Constraints can take many forms.

Agile Managementfor SoftwareEngineering

30

capacity of the constraint must be maximized. The CCR must be fully uti-lized. It must never be idle. Every unit of production (Q) lost on the con-straint is a unit of Q lost to the whole system. The constraint can beprotected from idleness by providing a buffer (or queue) of work for it to per-form. As a generalization, constraints are protected by buffers—a queue isjust a type of buffer, a physical buffer of inventory. Protecting a constraintis a necessary part of exploiting a constraint to the full. Achieving maxi-mum exploitation of a resource means that whatever can be done shouldbe done to utilize the CCR optimally. This is best explained with a coupleof examples.

Consider a manufacturing machine that cuts silicon wafers into individ-ual chips. Assume that this is the CCR for a chip fabrication plant. How canthe wafer cutter be protected and exploited as a CCR?

It can be protected from starvation by provision of a buffer of completedwafers. It can be protected from power outage with a provision of uninter-ruptible power and a backup generator. It can be exploited fully by runningthree shifts and utilizing the machine up to 24 hours per day. It can be exploitedby performing a prior quality control check on wafers to insure that only goodquality wafers are processed through the cutting machine.

Exploiting the Software Developer as a CapacityConstrained Resource

Consider a software development constraint. A software developer ispaid to work 8 hours per day. Strictly speaking, 8 hours per day is the con-straint. Of course, software developers tend to be flexible in their workinghours, so it might be more accurate to state that the constraint is the periodof time during which the developer shows up in the office. How can the soft-ware developer as a resource be protected and exploited?

She can be protected from idleness by always having a pool of devel-opment tasks ready to be done. She can be protected from interruptions byproviding a communication structure that minimizes the lines of commu-nication.2 She can be protected from distraction by providing a quiet envi-

Idea Analysis Design Code

UnitTest

SystemTest

AcceptanceTest

WorkingCode

ErrorErrorError100100 8080 5050 5050

8080 3030 5050

Figure 3–1Software productionsystem showing ratesof production.

2Harlan Mills wrote about the “Surgical Team” in 1971 as an example of a structure designedto minimize lines of communication and maximize the Throughput of software developers.

ronment for working. She can be further exploited by providing her withthe best software development tools available. She can be exploited byproviding support staff for nonproductive activities, such as progressreporting and time-tracking, or tools to automate such nonvalue-addedwork. Nonvalue-added work is waste. She can be exploited by providingadequate training in the technologies being used. She can be exploited byproviding a team of colleagues to support her and help resolve difficulties.She can be exploited by ensuring that the requirements she is given are ofgood quality. This represents just a short list of possible protection andexploitation mechanisms to maximize the completed working code pro-duced by a software developer.

Subordinating to the Exploitation of a ConstraintStep 3 in TOC requires subordination of all other things to a decision to

protect or exploit a constraint. Step 3 has profound implications for any busi-ness. The effect of step 3 can produce results that are counterintuitive and goagainst the existing management policies.

To continue with the fabrication plant example, assume that the capaci-ty of the wafer cutting tool has been determined. It has also been determinedthat the Throughput of the whole plant is constrained by the capacity of thewafer cutter. A decision is made to protect and exploit the wafer cutter to itsmaximum capacity. In order to subordinate all else to this decision, theremust be agreement to regulate the flow of inventory from the factory gate tothe wafer cutter at the same speed as the wafer cutter can process it. This isthe Drum-Buffer-Rope application of TOC. The rate of the cutter is the drum.The inventory from the factory gate to the cutter is the rope and a buffer infront of the cutter to prevent it becoming idle is the buffer. A similar processin Lean Production (or TPS) is known as “balancing” and results in the deter-mination of Takt time. Takt time plays the same role as the drum in Drum-Buffer-Rope. What this can mean in practice is that other machines earlier inthe process may lay idle. Part of the manufacturing plant may be idle becauseit would produce too much inventory were it to run 24 hours per day. Otherparts of the system must only produce as much as can be consumed by thewafer cutting machine.

The psychological effect of this subordination approach when first intro-duced can be overpowering. If the business is run using traditional costaccounting methods, then the idle machines appear to be very inefficientbecause efficiency is measured locally as the number of units processed perday/hour/minute. However, if the machines are not permitted to be idle, ifthere is no subordination of the rest of the plant to the decision to feedinventory at the speed the wafer cutter can cope with it, then inventory willbe stockpiled in front of the wafer cutter. The result will be that total inven-tory will grow and so will investment. Consequently, operating expense willgrow, too. The business will become less profitable and return less on theinvested capital. Leaving machines idle can be good for business, but it iscounterintuitive.

TOC in SoftwareProduction

31

Producing and holding too much inventory is much worse in software becauseof the perishable nature of the inventory—requirements can go stale becauseof changes in the market or the fickle nature of the customer. There is a timevalue to requirements, and they depreciate with time, just like fresh produce,that is, requirements have a time to market value. As time goes by, the poten-tial Throughput from the transformation of the requirement into working codedecreases. Increasingly often requirements become obsolete, and they arereplaced by change requests for new requirements with a current market value.

Staleness is a very profound problem in software development. Althougha requirement (unit of V) may be written down, there is an implicit body ofknowledge on how to interpret it. If it isn’t being actively processed, thatknowledge atrophies—people forget things! Even worse, people leave proj-ects or companies and take the knowledge with them.

For proof of this, ask a developer to explain how some code written 12months ago actually works, and see whether he can recall from memory or abrief analysis of the source code. Vital details never get captured, and peopleforget. Loss of memory and loss of detail incur extra costs. Such extra costscan be classified as waste.

Requirements that become stale are pure waste. Such requirements havea $0 potential Throughput value. When this happens, the cost of acquiringthe requirement must be written off as operating expense.

It ought to be possible to measure the average Production Rate (R), of adeveloper for any given week, or month, or quarter. For a team of developers,it should be possible to guess approximately how many requirements can beprocessed for a given time period. If they are to be fully exploited, developersshould not be loaded with any more than they can reasonably handle. So therest of the system of software production must be subordinated to thisnotion. Requirements should be fed into development at the same pace asthe developers can process them into completed code.

Again, the psychological effect of this decision when first introducedcould be devastating. If the requirements are generated by analysts who inter-view subject matter experts and business owners, management must realizethat those analysts no longer need to work flat out producing requirements. Ifdevelopment is the constraint, then by implication, analysis must not be theconstraint. It could be that the analysts will spend time idle. They are notrequired to create requirements constantly. In TOC language, this stop-goeffect is often called “Road Runner Behavior” after the Warner Bros. cartooncharacter who only has 2 speeds—full speed and stop. Road Runner behaviormay be bad for morale amongst the analysts. Hence, the Agile manager mustbe aware that the subordination step in TOC is dangerous and needs carefulmanagement attention during introduction.

Probably the best way to deal with this is to ensure that everyone under-stands the Drum-Buffer-Rope principles and that they are aware of the cur-rent system constraint. If they know that they do not work in the CCR, theyshould be comfortable with their new role being only partially loaded. Thistechnique of sharing an understanding of the system process and gainingbuy-in to changes has been called “Fair Process” [Kim 1997].

Agile Managementfor SoftwareEngineering

32

PerishableRequirements

IdlenessMight Breed

Contempt

Step 4 requires the elevation of the constraint. In plain English, this meansthat the constraint must be improved to the point where it is no longer thesystem constraint. This is best explained by example.

If the wafer cutting machine is the constraint in the fabrication plant,everything has been done to protect and exploit that machine, and everythingelse in the system has been subordinated to those decisions, but still thereis insufficient Throughput from the plant, the constraint must be elevated.With a machine, elevation is simple—buy and commission another machine.With the introduction of the second machine, the wafer cutter may no longerbe the constraint. The constraint within the system may have moved else-where. Management must now move to step 5 and identify the new con-straint. If the constraint has moved outside the system, then (arguably) theyare done.3 For example, if the plant can now produce more than the compa-ny can sell, the constraint has moved to sales. Managers at the fabricationplant no longer control the constraint. Hence, there is nothing they can do toimprove the Throughput of the business. If, however, the fabrication plantstill has an internal constraint, then the managers must return to step 1 andstart again.

Elevating the Software Developers Capacity ConstraintHow is the developer elevated from a constraint? The most obvious

method of elevation used in the software industry is unpaid overtime. Thedeveloper is asked to work longer hours. The constraint is stretched.Weekend work may also be requested. Again, the constraint is beingstretched. The manager could also choose to hire more developers or tointroduce shift working. Another very powerful method is to use a betterdeveloper.

It has been known for over 30 years [Weinberg 1971/1998] that some soft-ware developers produce much more output than others. Performance differ-ences between the average and the best of 10 to 20 times have beendocumented [Sackman 1968]. The difference between poor and best is possi-bly fifty fold. Hence, one way to truly elevate a software development organi-zation is to hire better people.

Good people are hard to find. In a large organization, management mustaccept that over the statistical sample, the engineering team will tend to beaverage. Hence, it is important that managers identify top performers, rewardand keep them, and apply them judiciously to projects where development isthe constraint. By using a top performer on a capacity constrained develop-ment project, management elevates the constraint and moves it elsewhere inthe value chain.

TOC in SoftwareProduction

33

Elevating aConstraint

3Lepore & Cohen merged the Theory of Constraints with Edwards Deming’s Theory ofProfound Knowledge and devised a 10-point scheme they call “The Decalogue” [Lepore,1999]. Stage 9 involves “bringing the constraint inside.”

Increasing Throughput by Elevating the ConstraintIn Figure 3–1, the System Test process is a bottleneck. It is constraining

the Throughput of the system to only 30 units per month. The equations inChapter 1 demonstrated the best way to be more profitable is to increaseThroughput. Figure 3–1 shows that it would be possible to raise theThroughput to 50 units per month if the System Test process was elevated. At50 units per month, System Test ceases to be the constraint. At that point,Design, Coding, Unit Test, and System Test are all joint constraints. Raisingproduction higher than 50 units per month would require investment to ele-vate all four of them. The business question to be answered is how much is itworth to increase the capacity of System Test from 30 to 50 units per month?

If TOC was to be summarized in a single word, it would be focus. TOC teachesmanagers where to focus investment. Whether it is investment of time,resources, or money, the largest ROI will be gained from investing in the cur-rently identified system constraint.

The financial equations for cost justification are simple. The existingequation for ROI is:

If the current constraint is eliminated through an Investment (dI), thenThroughput will increase by an amount (dT). The equation post-investmentwould look like

If ROIPost-Investment is greater than ROIPre-Investment the investment to removethe constraint is worth doing. In fact, the officers of the company, being awareof the option to invest and elevate the constraint, are legally obliged to theshareholders to make the investment—assuming funds are available.

It seems attractive to decide that there will be only one CCR in the system andthat it will be the working day. To simply assume that 8 hours is a constraintand that all personnel are constrained by it seems to provide a convenientoption for managers—they don’t have to look for other constraints.

Goldratt argues that the 8-hour work day is not a useful constraint becauseit is not a bottleneck [1994, chs. 30 & 31]. Rather, he would call this an insuffi-ciently buffered resource, that is, demand may outstrip supply. However, in thesystem of software production, a bottleneck would be a capacity constrainedresource (CCR) in front of which a stockpile of inventory is apt to accumulateand beyond which resources may starve for input. This definition of a constraintsatisfies the definition required for the Critical Chain [1997].

The capacity constrained resources (CCRs) that are most likely to repre-sent the bottlenecks are not generalist developers and testers but the spe-cialists such as UI designers, architects, data modelers, DBAs (performance

ROIPost-Investment =(T + dT) - OE

I + dI

ROIPre-Investment =Throughput (T) - Operating Expense (OE)

Investment (I)

Agile Managementfor SoftwareEngineering

34

Focus ofInvestment

Is the 8-HourDay the Best

Choice ofSystem

Constraint?

tuning wizards), visiting consultants, and maybe even subject matter experts(SMEs). Resources related to expert skills such as usability laboratories, stag-ing environments for performance tuning, prototyping laboratories, and test-ing labs can also be bottlenecks. Such resources are likely to be shared inlarge organizations and require scheduling. Sharing a resource and schedul-ing a date for its use introduces uncertainty into project management.

Bottlenecks in software production are identified by measuring the trend ininventory at each step in the process. The trend in inventory is affected by theproduction rate (or capacity) of each process step.

The overall production of the system should be balanced against thecapacity of the bottleneck. The bottleneck should be protected and exploitedin order to maximize its Throughput.

Management may choose to invest in the bottleneck in order to increaseits capacity and hence increase the overall production of code through thewhole system. The cost of the investment can be considered against the valueof the increased production that will be achieved. The use of TOC provides afocus for management, who may choose to employ Lean Thinking in order toelevate constraints and create improvement.

TOC in SoftwareProduction

35

Summary

305

Index

AAccounting for change, 180, 224, 245Accounting for rework, 224, 245–246Activity Based Costing (ABC), 26Adaptive behavior, emergence of, 109Agile management theory and roles, 109, 185Agile Manifesto principle, 12Agile methods

agility, defining, 293applicability of, 291business benefit of, 155–159expedite, as ability to, 293–294maturity progression, 297problem domain verus process map, 291process space, division of, 291–293scale versus ability to expedite, 294–295statistical process control, and, 295–296transferable quality improvement, 297–300

Agile software production metrics, 49Analysis maturity continuum, 280–282Anticipated ROI, use of, 111Archetypes, 181Artisan skills, 298, 299Attributing value to a release, 152–153Average Cost per Function (ACPF), 23, 54Average Investment per Function (AIPF), 75Average Investment per Function Point (AIPFP), 178Average Revenue per User per Month (ARPU), 150

BBatch size, role of, 88–89, 204Blocked inventory, 68Bottleneck

addition of staff to a, 119–120failure at unit test, 82in Feature Driven Development, 210identification of, 79–81at system test, 83–84

Brooks’ Law, 38, 274–275Budget buffers, 209Budget constraints, 41–42, 209Buffers, role of, 66–68, 98–99, 197–198, 207–209,

217–218

CCapacity constrained resource (CCR), 34, 146Cash cost per user per month (CCPU), 150Chaos theory, 10–11, 44, 278, 280Chief Programmer Work Packages (CPWP),

191–192, 197, 203–204Classification phase, 7Code inspections, effect of, 86Code reuse, 271Coding process time, 165–166Collective ownership approach, 239“Common cause” variation, 43

Complex Adaptive Systems, 11Conceptual learning, 297–300Continuous improvement, role of, 113Control charts, 5, 278Control states, 277–280Convergent versus divergent processes, 10Correlation phase, 7–8Cost accounting approach, 25–26, 141Cost benefit of quality, 87Cost control, 25Cost efficiency, 25Cost of change curve, 246–249Critical chain representations, 70, 196, 208Critical path, 64–65, 70, 216–217Cumulative delays, role of, 218Cumulative flow

bottleneck, use in identification of, 79–80in Extreme Programing (XP), 227in Feature Driven Development (FDD), 194monitoring, 90–93tracking inventory with, 53, 60–61

DData management, 184Defined versus empirical processes, 9–10Delivery date, protection of, 63, 68Design by feature set (step 4), 183Design process time, 165Developer resource constraint, 202Development manager, 73–74, 77Divergent versus convergent processes, 10Domain Neutral Component (DNC), 181, 211–212,

279, 283Drum beat, role of the, 95Drum-Buffer-Rope, 4, 68, 95

EEarly finish, failure to report, 218Early start, 65, 66EBITDA equation, 150–151Edge of Chaos state, 278, 280Effect-cause-effect phase, 8Effort-based metrics, 50Effort tracking, 56–57Emergence, 11–12Empirical versus defined processes, 9–10, 277–278End-to-end traceability, 113Enterprise Resource Planning (ERP). See

Manufacturing Resource Planning (MRP)

Epics, 226Estimated cost of project delivery (D), 23Evaporating clouds diagram, 272–273Expected return on investment, calculation of, 24Expediting requirements, effect of, 99–101Exploitation considerations and implications,

30–31, 201Extreme Programming (XP)

accounting for charge, in, 245accounting for rework, 245–246collective ownership approach, 239continuous integration, use of, 235cost of change curve, 246–249cumulative flow diagram, 227epics, 226expediting, and, 294financial metrics, 243–249goals of, 225integration testing, use of, 235–236inventory, 225–226, 243inventory cap, 229inventory tracking, 227–228investment, 229, 243–244lead time, 228, 284net profit equation in, 244on-site customer, role of the, 240operating expense in, 244option theory, 234pair programming, use of, 236–237pipelining, 229planning game, 234prioritization of stories, 234process step time, 228production metrics, 225–231, 288production rate, 227quality, focus on, 284raw material, 225refactoring, use of, 230, 239, 245–246regular work week, use of, 240return on investment in, 245risk philosophy, 229S-Curve, 248–249senior management, for, 230–231specialists, elimination of, 240stand-up meeting, use of the, 238statistical process control, and, 295–296story points, 225system representation, 226tasks, 226test driven development (TDD), 238testing, 229

Index

306

theory of constraints, denial of, 241throughput, 227, 244transferable quality improvement, 298–300unit testing, 238user stories, assessment of, 233–234

FFailure

at integration test, 82, 83, 86at product test, 84, 85at system test, 87on system test, 86at unit test, 81–82at user acceptance test, 84–85

Failure tolerant organization, role of the, 114“Fair Process,” 32Feature definition, 184–185Feature Driven Development (FDD)

accounting for change, 224accounting for rework, 224adaptation mechanisms, 189agile management theory, and, 185batch size, role of, 204bottleneck, test, 210budget buffers and constraints, 209buffers, role of, 197–198, 207–209, 209, 217–218build batches, 191–192build by chief programmer work package (Step

5), 183Chief Programmer Work Packages (CPWP),

191–192, 197, 203–204critical chain representation, 196, 208critical path, maintaining the, 216–217cumulative delays, role of, 218cumulative flow diagram, 194data management (DM), 184dependencies, role of, 218design by feature set (step 4), 183developer resource constraint, 202domain neutral component, 211–212early finish, failure to report, 218estimates versus agreed function, 194–195executive management metrics, 200exploitation of engineering resources, 201feature definition, 184–185feature lifecycle, 193feature list (Step 2), 182feature process steps, 196feature sets, 191–192feature team, use of, 202–203

file/class access constraint, 202financial metrics, 221–224five-point scale, 187–188formulae, 188–189inventory, 212–213, 221, 283–284inventory cap, role of, 209investment, 221–222knowledge management system, use of, 199lead time, 185level of effort (LOE), estimation of, 186–188local safety problem, 219modeling and analysis phase, 210–212modeling rule of thumb, 186morning roll call, use of, 213–215multitasking, role of, 218operating expense, 186, 222–223overview feature, 181–182peer reviews, use of, 210PERT charts, 195–196plan by subject area (Step 3), 183prioritized feature lists, use of, 204–206problem domain (business logic), 184process control, 193–194process steps, 185process time, 185production metrics, 182–189, 287–288project parking lot, 198quality, focus on, 283–284queue time, 185return on investment, 224safety constraints, 217–218scheduling subject areas and feature sets,

195–197scope constraint, 204–205S-Curve effect, and, 215–216self-organizing construction within planned

assembly, 191setup time, 185, 203shape modeling, 182, 216“student syndrome,” 217–218subject areas, 193surgical team, use of, 202–203system representation, 182–183systems interfaces (SI), 184ten percent (10%) rule, 219–220Threshold state, and, 279–280throughput, 223time constraints, 207–209, 216–217time-modified prioritized feature lists, use of,

205–206transferable quality improvement, 298–300

Index

307

user interface feature sets, 192user interface (UI), 184value-added, 223variance, focus on, 283visual control, 199wait time, 185workflow, 197–198

Feature lifecycle, 193Feature sets, 191–192Feature team, use of, 202–203Feedback, role of, 11Feeding buffers, 66File/class access constraint, 202Financial metrics

in Extreme Programing (XP), 243–249in Feature Driven Development (FDD), 221–224for general business systems, 21for software development systems, 22for software services, 149–154

Fire fighting, 298, 299Five-point scale, 187–188Flow, identification of, 77–78Foreseen uncertainty, 43Framework, development of, 24–25Functional priority, 40Function Point (FP), 164, 177, 289

GGeneral Accepted Accounting Practices (GAAP), 27General business systems, 21Governing rules

adaptive behavior, emergence of, 109anticipated ROI, use of, 111continuous improvement, role of, 113end-to-end traceability, 113engineers, for, 115failure tolerant organization, role of the, 114management roles and rules, 109, 112maturity increases, as, 111–112process improvement problem, 110production metrics, 111, 113Reinersten’s Three Tiers of Control, 109–110skills gap education, 113team measurements, 115

“Green” status, 68Group inventory for convenient testing, 64

IIdeal State, 278, 279Idleness, role of, 32–33Input, value of, 58

Integration testing, 79, 86, 87, 235–236Intellectual efficiency, 88, 166Inventory

in Extreme Programing (XP), 225–226, 243in Feature Driven Development (FDD), 221,

283–284group inventory for convenient testing, 64importance of, 27logical collections of, 63–64in Scrum, 252–253in Software Development Lifecycle (SDLC), 164tracking the flow of, 60–61in traditional methods, 177unified development process (UDP), 172

Inventory capin Extreme Programing (XP), 229in Feature Driven Development (FDD), 209in Scrum, 255in Software Development Lifecycle (SDLC), 165in Unified Development Process (UDP), 173

Inventory tracking, 227–228, 254Investment

in Extreme Programing (XP), 229, 243–244in Feature Driven Development (FDD), 221–222reductions in, 134in Scrum, 255in Software Development Lifecycle (SDLC), 164in traditional methods, 177–178in Unified Development Process (UDP), 172

Investment value, throughput accounting trackingof, 58–59

ISO-9000, 5Issue log, 68IT department, agile management in the

budget basis for IT assessment, calculation of,133

budget basis for measuring the IT organization,131–132

investment, reductions in, 134lead time, reduction of, 135operating expenses, reductions in, 135throughput, improvements in, 134true basis, calculation of, 132–133value-added by a bank lending system,

potential definitions for, 132value-added contribution, corporate IT’s, 131–132

Iterative incremental process, 173, 174

JJ-Curve effect, 38, 274–276JIT. See Just-in-Time InventoryJust Enough Design Initially (JEDI), 6, 283

Index

308

KKanban Approach, 4, 6Knowledge Management System (KMS), use of,

93, 199Koskela & Howell’s three-dimensional model for

project management, 57

LLabor, implications of adding additional, 274–276Late start, 65–66“Late” status, 68Lead time (LT)

estimation of, 63in Extreme Programing (XP), 228in Feature Driven Development (FDD), 185reduction of, 135in Scrum, 254, 285in Software Development Lifecycle (SDLC), 164and software production metrics, 53in Unified Development Process (UDP), 173

Lean production, 5–6, 284Learning Organization Maturity Model

goals of, 105Stage 0-Analysis Ability, 105Stage 4- Anticipated ROI and the Failure

Tolerant Organization, 107Stage 1-End-to-End Traceability, 106Stage 2-Stabilize System Metrics, 106Stage 3- Systems Thinking and a Learning

Organization, 106–107Level-of-effort (LOE) estimate, 50, 186–188Lifecycle methods, software engineering, 18Lifetime revenue per subscriber (LRPS), 150Line of code (LOC), 50Little’s Law, 53Local safety considerations, 44–46, 219

MManagement accounting for systems

complex development systems, 18–20emergent properties, 14operating expenses (OE), 15systems thinking, and, 14–15throughput accounting, and, 15–17value added, and, 16

Management roles and rules, 73–76, 109, 112Manufacturing Resource Planning (MRP), 95Marketing Requirement Document (MRD), 171Maturity progression, 297Morning roll call, use of, 213–215Multitasking, role of, 218

NNet profit, 21–22, 24, 179, 244Net profit for services (NPBITDA), calculation of,

152

OObject Oriented Analysis, 8Object Oriented Software Engineering (OOSE),

289Offshore development and process maturity,

121–122One-dimensional model of project management,

57On-going investment, role of, 142On-site customer, role of the, 240“On Time” status, 68Operating expense (OE)

in Extreme Programing (XP), 244factors of, 146in Feature Driven Development (FDD), 222–223importance of, 27operating expense for services (OEBIDA),

calculation of, 151reductions in, 135in traditional methods, 178–179

Operational learning, 297–300Operationally validated theories, 298Operations review

attendees, 123financial information, presentation of, 124–125information, presentation of, 124–128minute taking, 128production metrics, presentation of, 125–126program management metrics, presentation of,

127project management metrics, presentation of,

127purpose of, 123timing, 124

Option theory, 234Outsourcing decisions, 120–122Overtime, effectiveness of, 81

PPair programming, use of, 236–237Parallel paths, definition and identification of,

64–65Peer reviews, use of, 210People constraint, protecting the, 37–38Perishable requirements, 32

Index

309

PERT charts, 64, 69, 195–196Pipelining, 229, 256Plan by subject area (Step 3), 183Planning game, 234PMI models for project management, 55Predictions of profitability, 23–24Prioritized feature lists, use of, 204–206Problem domain, 184, 291Process improvement, role of, 110, 138Process lead time, elements of, 88Process map, problem domain versus, 291Process maturity, improvements in, 282–283, 285Product backlog, 251, 259Production efficiency, 26Production metrics

in Extreme Programing (XP), 225–231in Feature Driven Development (FDD), 182–189,

287–288governing rules, 113in Scrum, 251–2562, 288–289

Production quantity, measuring, 52Production rate (R)

in Extreme Programing (XP), 227governing rules, 111representation, 79in Scrum, 253in Software Development Lifecycle (SDLC), 165in Unified Development Process (UDP), 173

Product line strategy, 74Product management, agile

cost accounting for Software ProductDevelopment, 141

management accounting, 138on-going investment, role of, 142operating expense, factors of, 146process improvement, role of, 138product mix, role of, 142–148sales and throughput, calculation of, 137–138scope constraint, management of, 143–144throughput accounting approach, 138–142time-based throughput model, appropriateness

of the, 140traditional cost accounting approach, 138

Product manager, 74–75Product mix

constraints, and, 146–148effect on investment, and, 146revenue is the goal, when, 144–145role of, 142–143, 154

Profitability, predictions of, 24

Profit by service release, calculation of, 153Program manager, 74Project buffer, 63, 119–120Project delivery date, protection of, 63Project manager’s new work, development of, 59–60Project parking lot, 198“Project” status, 68

“late” status, 68“on time” status, 68“red” status, 68“watch” status, 68“yellow” status, 68

QQA. See Quality assurance, importance ofQuality assurance, importance of, 5, 6, 81, 86–88,

277Queue growth, 79Queue time, 88, 175, 185

RRapid Application Development (RAD)

inventory cap in, 265lead time in, 266limitations of, 266–267operating expense in, 266principles of, 265

Raw materialin Extreme Programing (XP), 225in Scrum, 252in Unified Development Process (UDP), 171

Recovery and stretch of software productionconstraints, 81

“Red” status, 68Refactoring, 93, 230, 239, 245–246, 257Regression effects, 85Reinersten’s Three Tiers of Control, 109–110Release, 260–261Release backlog, 251, 259Release manager, 74Resource constraints, 42–43, 68–70Return on Investment, 4, 21, 24, 152–153, 179, 224,

245Rigorous Software Methodologies (RSM), 292,

296, 299Risk philosophy, 229, 256ROI. See Return on InvestmentRoles versus functions, agile management, 76

Index

310

SSafety constraints, 217–218Sales and throughput, calculation of, 137–138Scheduling subject areas and feature sets,

195–197Scientific development, phases of, 7–9Scientific management paradigm, 56Scope constraint, 40–41, 143–144, 204–205Scrum

cumulative flow, 253engineering practices, 263expediting policy, 255, 260, 285, 294goal commitment, 261goals of, 251inventory, 252–254inventory cap, 255investment, 255lead time, 254, 285meeting, daily, 261pipelining, 256process step time, 255product backlog, 251, 259production metrics, 251–257, 288–289production rate, 253products, 251raw material, 252refactoring, 257release, 251, 260–261release backlog, 251, 259review process, 263risk philosophy, 256Scrum Master, 259senior management metrics, 257sprint backlog, 251, 259sprint planning and project management, 254sprints, 251statistical process control, and, 295–296system representation, 252team size and composition, 261–262testing, 256thirty day sprint, 260throughput, 253transferable quality improvement, 298–300working environment, 262–263

S-Curve, 90–93, 215–216, 248–249SEI Software Capability Model, 105Self-organizing construction within planned

assembly, 191Service business economics, 150

Setup time, 88, 175, 185, 203Shape modeling, 182, 216Six Sigma, 6Skills gap education, 113Software Development Lifecycle (SDLC)

analysis process time, 165coding process time, 165–166design process time, 165Function Point (FP) metric, 164idleness, efficiency, and growing inventory

levels, 170inventory, 164, 166–167inventory cap, 165investment, 164lead time, 164process step time, 165–166production rate, 165raw material, functional specification for, 163slack, lack of, 170specialists and high inventory levels, 169–170testing process time, 166throughput, 164–165uncertainty, role of, 168variance reduction and waste, 168–169waste and long lead times, 167

Software production metricsagile software production metrics, 49Average Cost Per Function (ACPF), 54effort-based metrics, 50expressions of inventory, 52inventory-based metrics, 49lead time (LT), and, 53level-of-effort estimate, 50measurement of inventory, 51–52nonfunctional requirements, 51OE per unit, 54production quantity, measuring, 52selection of, 49tracking inventory, 53traditional software production metrics, 50

Software Resource Planningbuffers, role of, 98–99drum beat, role of the, 95expediting requirements, effect of, 99–101goals of, 95release of requirements into the systems,

planning, 96starving a process, effect of, 97–98subordination of the CCR, 95swamping a process, effects of, 96–97

Index

311

Theory of Constraints, and, 95waste, cost and causes of, 101–103

Software services, financial metrics forattributing value to a release, 152–153average revenue per user per month (ARPU),

150cash cost per user per month (CCPU), 150definition of software service, 149EBITDA equation, 150–151lifetime revenue per subscriber (LRPS), 150net profit for services (NPBITDA), calculation of,

152operating expense for services (OEBIDA),

calculation of, 151product mix, role of, 154profit by service release, calculation of, 153return on investment for services, calculation

of, 152ROI by service release, calculation of, 153service business economics, 150throughput for service, calculation of, 150–151uncertainty, role of, 154

SPC theory. See Statistical Process Control theorySpecialists

availability of, 69elimination of, 240versus generalists, use of, 272–274high inventory levels, and, 169–170

Sprint backlog, 251, 259Sprint planning and project management, 254Sprints, 251Staffing decisions

bottleneck, addition of staff to a, 119–120conventional view of turnover costs, 117full-time engineer, cost of replacing a, 118loss of throughput on a constraint, 118–119offshore development and process maturity,

121–122outsourcing decisions, 120–122project buffer, impact on, 119–120temporary engineer, cost of replacing a, 118–119throughput accounting view of turnover costs,

117turnover, role of, 117

Stand-up meeting, use of the, 238Starving a process, effect of, 97–98Statistical Process Control Theory, 5, 277, 295–296Story points, 225“Student syndrome,” 217–218Subject areas, 193Subject matter expert (SME), 221

Subordination, 31, 95Surgical team, use of, 202–203Swamping a process, effects of, 96–97System Goal, 20Systems interfaces (SI), 184Systems thinking and learning organizations, 11

detail complexity, 15general systems, 13–17inherent complexity, 15

System testing, 79, 83–84, 86, 87

TTask planning, 56–57Tasks, 226Taylorism, 169

Taylor, Frederick Winslow, 169scientific management, 56

Team measurements, 115Team size and composition, 261–262Ten percent (10%) rule, 219–220Test driven development (TDD), 238Theoretical comparison, 6–7Theory of Constraints, 3–4, 6, 11, 29–34, 95, 241Theory of Scientific Management, 25Thirty day sprint, 260Three-dimensional model for project

management, 57Threshold state, 278, 279–280Throughput

in Extreme Programing (XP), 227, 244in Feature Driven Development (FDD), 223importance of, 27improvements in, 134increasing, 34in Scrum, 253in Software Development Lifecycle (SDLC),

164–165in traditional methods, 179in Unified Development Process (UDP), 173

Throughput accounting, 19–20, 21, 25–26, 117,139–140, 141–142

Tick-IT, 5Time-based throughput model, appropriateness

of the, 140Time constraints, 38–40, 207–209, 216–217Time-modified prioritized feature lists, use of,

205–206Total Quality Management, 5, 6Toyota Production System, 4, 6TQM. See Total Quality Management

Index

312

Tracking metrics, agile project, 67–68Traditional cost accounting approach, 138Traditional metrics versus agile principles, 271, 289Traditional project management, 55–56Traditional software production metrics, 50Transferable quality improvement, 297–300,

298–300Transformation, stages of, 18–19True basis, calculation of, 132–133Trust, goal of establishing, 41Turnover, role of, 117

UUncertainty

aggregation of sequential and parallelprocesses, 46–47

budget constraint, protecting the, 41–42chaos, 44classification of, 43–44foreseen uncertainty, 43local safety considerations, 44–46people constraint, protecting the, 37–38principle of, 11, 37resource constraints, protecting the, 42–43role of, 154, 168scope constraint, protecting the, 40–41time constraint, protecting the, 38–40unforseen uncertainty, 44variation, 43

Unforseen uncertainty, 44Unified Development Process (UDP)

agility, lack of, 175–176artifacts, 174documentation, 174inventory, 172inventory cap, 173investment phase, 172iterative incremental process, 173, 174lead time, 173process step time, 175process time, 175production rate, 173project management, 175queue time, 175raw material, 171setup time, 175throughput, 173use cases, 172vision document, 171wait time, 175

Unit testing, 82, 238Unvalidated theories, 298, 299Use cases, 172, 289–290User interface feature sets, 192User interface (UI), 184User stories, assessment of, 233–234

VValue-added

by a bank lending system, potential definitionsfor, 132

contribution to corporate IT’s, 131–132cost accounting tracking of, 57–58in Feature Driven Development (FDD), 223

Value chain, software production in the, 25Value efficiency, 26Variance, 43, 168–169, 283Vision document, 171Visual control, 93–94, 199

WWait time, 89, 175, 185Waste, 101–103, 167“Watch” status, 68“Waterfall” model for software production, 56, 161,

166–168. See also Software DevelopmentLifecycle (SDLC)

Wheeler’s four states of control, 278, 295–296Working capital requirements, determination of,

23–24Working code (Q), 23Work-in-process (WIP) inventory, 65, 166

Y“Yellow” status, 68

Index

313