Agile Management for Software Engineering (The Coad Series) / Edition 1

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $5.41
Usually ships in 1-2 business days
(Save 92%)
Other sellers (Paperback)
  • All (16) from $5.41   
  • New (7) from $45.85   
  • Used (9) from $5.36   

Overview

"This book does a good job of describing the methods employed at Sprintpcs.com ... over 250 people practicing Feature Driven Development and reporting their progress to me at the monthly operations review."
--Scott B. Relf, Chief Marketing Officer, Sprint PCS

"A tremendous contribution to the literature in the field. This should be required reading for all development teams going forward."
--John F. Yuzdepski, VP & GM, Openwave Systems

A breakthrough approach to managing agile software development, Agile methods might just be the alternative to outsourcing. However, agile development must scale in scope and discipline to be acceptable in the boardrooms of the Fortune 1000. In Agile Management for Software Engineering, David J. Anderson shows managers how to apply management science to gain the full business benefits of agility through application of the focused approach taught by Eli Goldratt in his Theory of Constraints.

Whether you're using XP, Scrum, FDD, or another agile approach, you'll learn how to develop management discipline for all phases of the engineering process, implement realistic financial and production metrics, and focus on building software that delivers maximum customer value and outstanding business results.Coverage includes:

  • Making the business case for agile methods: practical tools and disciplines
  • How to choose an agile method for your next project
  • Breakthrough application of Critical Chain Project Management and constraint-driven control of the flow of value
  • Defines the four new roles for the agile manager in software projects-- and competitive IT organizations

Whether you're a development manager, project manager, team leader, or senior IT executive, this book will help you achieve all four of your most urgent challenges: lower cost, faster delivery, improved quality, and focused alignment with the business.

Read More Show Less

Product Details

  • ISBN-13: 9780131424609
  • Publisher: Prentice Hall
  • Publication date: 9/15/2003
  • Series: Coad Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 313
  • Product dimensions: 7.00 (w) x 8.90 (h) x 0.90 (d)

Meet the Author

DAVID J. ANDERSON has been in the software business for more than 20 years, with experience as a developer and manager in start-up environments and in three of the world's largest companies. He was a member of the team that created Feature Driven Development. David is currently Director of Emerging Technology with 4thpass Inc., a Motorola subsidiary based in Seattle, WA.

Read More Show Less

Read an Excerpt

Foreword

It is so good to finally have a book targeted at the software industry that challenges some of the basic business assumptions behind software engineering, and particularly those behind managing software organizations. At the time these words are written, the software business is facing huge difficulties worldwide. I hope that these difficulties also generate a willingness to look afresh at the business and to have the courage to contemplate changes. Other industries, particularly in manufacturing, went through such conceptual changes in their business processes during the 1980s and the 1990s. It is certainly 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 proud with my new package for certified public accountants. But, even though my package competed very nicely in the market, I noticed an on-going business problem: More and more development was needed to keep the package alive. In such a case, how do I justify the on-going investment? Eventually, I was not sure that a small software company, focused on a specific market niche, could be a good business—even when the product itself was enthusiastically accepted by the market. I felt that even though I already had my MBA, I needed a better perspective 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 excellent and innovative software company. It challenged some of the most sacred norms of business, such as the concept of product cost. I could not understand how anyone couldchallenge the basic concept that a unit of a product has a certain cost associated with it. I was intrigued enough to be open to an offer: Join Creative Output in order to develop a video game for managers that would deliver some new managerial ideas. At the time, computerized games were focused on fast fingers and perfect coordination. They were certainly not something of interest to adults. How could a computer game be readily accepted by grown-up managers and deliver new managerial ideas?

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

The relevance of the Theory of Constraints (TOC) to the software industry is twofold:


  1. Vastly improving the flow of new products to the market.
  2. Determining the real value of a proposed project, or even just a feature, to the final user. The underlying assumption is that if we know the real value to the user, it is possible to develop the right marketing and sales approach to materialize the value to the user and to the software organization.

David Anderson focuses mainly on the first aspect in this book, which includes looking at the business case and ensuring the ability to make it happen. Software organizations can definitely be improved with the help of the new generic managerial insights that have already changed traditional western industries. David does a great job in bringing together the generic managerial ideas and rationale and combining them with software-focused approaches to come up with a coherent approach on how to improve the business.

Read this book carefully with the following objective: Learn how to make more with less. Don't accept every claim David raises just because he says it is so. If you truly want to make more with less, you need to be able to internalize the claim. All I ask is you give it a chance. Dedicate time in order to rethink your environment, and then see for yourself what to do. Overcoming inertia 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 open mind and confronting new ideas that invalidate basic assumptions are what I suggest you strive for. This book is for you to struggle with. It is not trivial, and it is not a fad. If you like what you do now, it should be your responsibility to check out new ideas that might yield huge improvements.

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

A new Feature can bring value to the user only if it eliminates, or vastly reduces, an existing limitation. The amount of the value depends on the limitation removed—not on the sophistication of the feature itself. Let us take 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 good knowledge of the language, spelling mistakes are caused by writing too fast. So, without a spell checker, those people need to read carefully what they just wrote. 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 time consuming.

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 wrote before sending the document to others. People without good command of the language needed to be supported by a dictionary.

Once the limitation is vastly reduced, people should replace the old rules with new ones that take full advantage of the removal of the limitation. 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 word processor brings value. Suppose you have perfect command in the language, would you now refrain from carefully reading your recent document before sending it away? Spelling mistakes are hardly the main reason to go over any document that I want other people to read. So, for people with perfect knowledge, the spell checker offers no real value. But, for me as a person in good command of Hebrew, but not good enough in English, spelling mistakes in English are a nuisance. But, could I really avoid them just by the use of a spell checker? As long as the spell checker does not suggest how to write the word correctly—the limitation is only marginally reduced and thus not much value is produced. This means that if we want to generate significant value for the specific user group that has not mastered the language, we need to add good suggestions of what should be written instead.

In this simplified example, we already see the need to check the behavior rules both before the limitation is eliminated and after. Is it always clear what the new behavior rules should be? Assuming the user is well aware of what the new rules should be is a very common trap for too many software features.

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

What should the new management rules be once management knows whether the rise in sales is significant? I'm afraid that in the vast majority of the cases the behavior will be exactly the same. Hence, the newly added Feature will not add value to the customer, even though some customers might ask for it and even exert a lot of pressure to have the Feature developed. Eventually, the value to the software company of developing the Feature will be negative.

Of course, for a good managerial consultant assisting in the formation of better decision processes, a specific Feature can bring immense value both to the consultant and the client. In this case, a strategic partnership between 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 customer and also have a good chance of generating revenues for the software organization is what this unique book is all about. The Agile Manifesto principle of "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" is fully in line with the Theory of Constraint's objectives. To be more precise, TOC strives to generate more of the organization's goal. But, in order to do so, the organization has to generate more value to its customers. The means of early and continuous delivery of software that truly generates value should assist both the software organization and its clients in achieving more of their respective goals.

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

—Eli Schragenheim

Read More Show Less

Table of Contents

Foreword.

Introduction.

Acknowledgements.

SECTION I. AGILE MANAGEMENT.

1. Theories for Agile Management.

The Theory of Constraints. Just-in-Time Inventory. Quality. Lean Production. Six Sigma. Comparison of Theories. Scientific Proof for Agile Management. Empirical Versus Defined Processes. Convergent Versus Divergent Processes. Chaos Theory and Uncertainty. Systems Thinking and Learning Organizations. Emergence. Summary.

2. Management Accounting for Systems.

A General System. Detail Complexity Versus Systems Complexity. Throughput Accounting for General Systems. A System of Software Development. A More Complex Software Development System. The System Goal. Financial Metrics for General Business Systems. Financial Metrics for Software Development Systems. Predicting the Future. Framing the Problem. Understanding Software Production in the Value Chain. Throughput Accounting Versus Cost Accounting. Summary.

3. TOC in Software Production.

TOC's Five Basic Steps. Identify and Exploit Constraints. Perishable Requirements. Idleness Might Breed Contempt. Elevating a Constraint. Focus of Investment. Is the 8-Hour Day the Best Choice of System Constraint? Summary.

4. Dealing with Uncertainty.

The Five Constraints of Software Development. Aggregation Reduces Uncertainty. Summary.

5. Software Production Metrics.

Choosing Metrics. Agile Software Production Metrics. Traditional Software Production Metrics. Measuring Inventory in the Software Production System. Expressions of Inventory. Measuring Production Quantity. Lead Time. OE per Unit. Summary.

6. Agile Project Management.

Traditional Versus RAD Model for Project Management. Task Planning and Effort Tracking. The Project Manager's New Work. Summary.

7. Agile Project Planning.

The Project Buffer. Logical Collections of Inventory. The Critical Path and Parallel Paths. Early Start. Late Start. Feeding Buffers. Buffer Usage. Agile Project Tracking Metrics. Resource Constraints. Critical Chain Versus Critical Path. Summary.

8. The Agile Manager's New Work.

New Roles for Agile Managers. Development Manager Role. The Program or Release Manager Role. Product Manager Role. Project Manager Role. Roles Versus Positions.

9. Agile Development Management.

The Role of the Development Manager. Identifying Flow. Identifying a Bottleneck. The True Cost of a Bottleneck. Recovering and Stretching Software Production Constraints. The True Cost of Poor Quality. Regression Effects. Improve Quality in Front of a Bottleneck. How Batch Sizes Affect Flow. Monitoring Cumulative Flow. Visual Control. Summary.

10. Software Resource Planning.

Manufacturing Resource Planning (MRP). Drum Beat. Planning Release of Requirements into the System. Summary.

11. An Agile Maturity Model.

A New Maturity Model. Summary.

12. Setting the Governing Rules.

Allow Adaptive Behavior to Emerge. The Role of the Agile Executive. Reinertsen's Three Tiers of Control. The Process Improvement Problem. The Problem with Production Rate Metrics. Governing Rules as Maturity Increases. Governing Rules for Managers. Governing Rules for Engineers. Team Measurements.

13. Staffing Decisions.

Turnover. Loss of Throughput on a Constraint. Understanding the System Constraint is Essential. Outsource Decisions.

14. Operations Review.

Purpose. Attendees. Timing. Information Rather Than Data. Summary.

15. Agile Management in the IT Department.

Corporate IT's Value-Added Contribution. Learning from Financial Metrics. A More Profitable Corporate IT Department. Summary.

16. Agile Product Management.

Sales and Throughput. Learning Is Not Restricted to Engineering. Management Accounting for Product Development. Throughput Accounting for Software Product Development. Appropriateness of the Time-Based Throughput Model. Cost Accounting for Software Product Development. Throughput Versus Cost Models. Making On-Going Investment. Product Mix. Managing the Scope Constraint. Product Mix When Revenue Is the Goal. Product Mix and the Effect on Investment. Product Mix, Risk, and Delay and the Effect on Operating Expense. Summary.

17. Financial Metrics for Software Services.

Defining a Software Service. Service Business Economics. Determining Throughput for Software Services. Operating Expense for Services. Net Profit for Services. Return on Investment for Services. Attributing a Value to a Release. Profit and ROI by Service Release. Product Mix. Dealing with Uncertainty.

18. The Business Benefit of Agile Methods.

The Principles of Agile Methods. More Than Agility. Making Profitable Development Happen.

SECTION II. A SURVEY OF METHODS.

19. Production Metrics for Traditional Methods.

SDLC. Unified Development Process.

20. Financial Metrics in Traditional Methods.

Inventory. Investment. Operating Expense. Throughput. Net Profit in Structured Methods. Return on Investment in Structured Methods. Accounting for Change.

21. Production Metrics in FDD.

Overview of Feature Driven Development (FDD). Feature Definition. Agile Management Theory and FDD. Process Steps and FDD. Estimating OE for an FDD Project. The Modeling Rule of Thumb. Level of Effort Estimation in FDD. Formulae for Success.

22. Project Management with FDD.

Self-Organizing Construction within Planned Assembly. Feature Sets. Build Batches. User Interface Feature Sets. Subject Areas. The Feature Lifecycle. Process Control in FDD. Estimates Versus Agreed Function. Scheduling an FDD Project. Scheduling Subject Areas and Feature Sets. FDD Workflow. FDD Knowledge Management System and Visual Control. Executive Management Metrics in FDD.

23. FDD Process Elements Explained.

Exploiting Engineering Resources. The File Access Constraint—Class Ownership. The Developer Resource Constraint—Feature Teams and the Surgical Team. The Setup Time Constraint—Chief Programmer Work Packages. Batch Size. The Scope Constraint—Prioritized Feature Lists. The Time Constraint and Buffers. The Budget Constraint—Inventory Cap and Buffer. The Test Bottleneck. Advanced Modeling Techniques. Inventory Management in FDD. Morning Roll Call. How FDD Improves the S-Curve Effect. The Time Constraint Revisited. The Local Safety Problem. Exploiting Heroic Effort.

24. Financial Metrics in FDD.

Inventory in FDD. Investment in FDD. Operating Expense in FDD. Throughput in FDD. Value-Added in FDD. Return on Investment in FDD. Accounting for Change. Accounting for Rework. Avoid Double-Counting.

25. Production Metrics in Extreme Programming.

Metrics in XP. Raw Material. Inventory. Tasks. Throughput. Production Rate. Inventory Tracking. Lead Time. Process Step Time. Inventory Cap. Investment. Risk Philosophy. Testing. Pipelining. Refactoring. Metrics for Up-Management in XP.

26. XP Process Elements Explained.

Assessing User Stories. Prioritizing Stories. Option Theory. The Planning Game. Continuous Integration. Integration Testing. Pair Programming. Stand-Up Meeting. Unit Testing. Collective Ownership. Refactoring. 40-Hour Week. On-Site Customer. Generalists. Elimination Versus Protection, Subordination, and Elevation.

27. Financial Metrics in XP.

Inventory in XP. Investment in XP. Operating Expense in XP. Throughput in XP. Net Profit in XP. Return on Investment in XP. Accounting for Change. Accounting for Rework. The Cost of Change Curve.

28. Production Metrics in Scrum.

Background. Raw Material. Inventory. Throughput. Production Rate. Metrics. Sprint Planning and Project Management. Inventory Tracking. Lead Time. Process Step Time. No Expediting. Inventory Cap. Investment. Risk Philosophy. Testing. Pipelining. Refactoring. Metrics for Up-Management in Scrum.

29. Scrum Process Elements Explained.

The Scrum Master. The Product Backlog. The 30-Day Sprint. Release. The Sprint Goal Commitment. The Scrum Meeting. Team Size. Team Composition. Working Environment. The Sprint Review. Engineering Practices.

30. RAD Process Elements Explained.

Principles of RAD. Inventory Cap. Lead Time. Operating Expense. Limits of RAD Methods.

SECTION III. COMPARISON OF METHODS.

31. Devil's Advocacy.

Traditional Metrics Versus Agile Principles. Specialists Versus Generalists. Adding More People Makes Projects Later.

32. States of Control and Reducing Variation.

The Ideal State. The Threshold State. The Edge of Chaos State. Chaos. Comprehending the Known Universe. Improving Analysis and Modeling Maturity. Improving the Process Maturity. FDD Focuses on Variance as Well as Quality and Inventory. XP Focuses on Quality and Short Lead Times. Comparison of Method Focus. Seek Process Maturity.

33. Comparison of Production Metrics.

FDD. Extreme Programming. Scrum. Traditional Methods—Function Points. Traditional Methods—UDP. Summary.

34. Applicability of Agile Methods.

Dividing up the Process Space. What is Agility? Scale Versus Ability to Expedite. Statistical Process Control and Agile Methods. What Does This Mean? Transferable Quality Improvement. Summary.

Index.

Read More Show Less

Preface

Foreword

It is so good to finally have a book targeted at the software industry that challenges some of the basic business assumptions behind software engineering, and particularly those behind managing software organizations. At the time these words are written, the software business is facing huge difficulties worldwide. I hope that these difficulties also generate a willingness to look afresh at the business and to have the courage to contemplate changes. Other industries, particularly in manufacturing, went through such conceptual changes in their business processes during the 1980s and the 1990s. It is certainly 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 proud with my new package for certified public accountants. But, even though my package competed very nicely in the market, I noticed an on-going business problem: More and more development was needed to keep the package alive. In such a case, how do I justify the on-going investment? Eventually, I was not sure that a small software company, focused on a specific market niche, could be a good business--even when the product itself was enthusiastically accepted by the market. I felt that even though I already had my MBA, I needed a better perspective 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 excellent and innovative software company. It challenged some of the most sacred norms of business, such as the concept of product cost. I could not understand how anyone could challenge the basic concept that a unit of a product has a certain cost associated with it. I was intrigued enough to be open to an offer: Join Creative Output in order to develop a video game for managers that would deliver some new managerial ideas. At the time, computerized games were focused on fast fingers and perfect coordination. They were certainly not something of interest to adults. How could a computer game be readily accepted by grown-up managers and deliver new managerial ideas?

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

The relevance of the Theory of Constraints (TOC) to the software industry is twofold:

  1. Vastly improving the flow of new products to the market.
  2. Determining the real value of a proposed project, or even just a feature, to the final user. The underlying assumption is that if we know the real value to the user, it is possible to develop the right marketing and sales approach to materialize the value to the user and to the software organization.

David Anderson focuses mainly on the first aspect in this book, which includes looking at the business case and ensuring the ability to make it happen. Software organizations can definitely be improved with the help of the new generic managerial insights that have already changed traditional western industries. David does a great job in bringing together the generic managerial ideas and rationale and combining them with software-focused approaches to come up with a coherent approach on how to improve the business.

Read this book carefully with the following objective: Learn how to make more with less. Don't accept every claim David raises just because he says it is so. If you truly want to make more with less, you need to be able to internalize the claim. All I ask is you give it a chance. Dedicate time in order to rethink your environment, and then see for yourself what to do. Overcoming inertia 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 open mind and confronting new ideas that invalidate basic assumptions are what I suggest you strive for. This book is for you to struggle with. It is not trivial, and it is not a fad. If you like what you do now, it should be your responsibility to check out new ideas that might yield huge improvements.

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

A new Feature can bring value to the user only if it eliminates, or vastly reduces, an existing limitation. The amount of the value depends on the limitation removed--not on the sophistication of the feature itself. Let us take 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 good knowledge of the language, spelling mistakes are caused by writing too fast. So, without a spell checker, those people need to read carefully what they just wrote. 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 time consuming.

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 wrote before sending the document to others. People without good command of the language needed to be supported by a dictionary.

Once the limitation is vastly reduced, people should replace the old rules with new ones that take full advantage of the removal of the limitation. 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 word processor brings value. Suppose you have perfect command in the language, would you now refrain from carefully reading your recent document before sending it away? Spelling mistakes are hardly the main reason to go over any document that I want other people to read. So, for people with perfect knowledge, the spell checker offers no real value. But, for me as a person in good command of Hebrew, but not good enough in English, spelling mistakes in English are a nuisance. But, could I really avoid them just by the use of a spell checker? As long as the spell checker does not suggest how to write the word correctly--the limitation is only marginally reduced and thus not much value is produced. This means that if we want to generate significant value for the specific user group that has not mastered the language, we need to add good suggestions of what should be written instead.

In this simplified example, we already see the need to check the behavior rules both before the limitation is eliminated and after. Is it always clear what the new behavior rules should be? Assuming the user is well aware of what the new rules should be is a very common trap for too many software features.

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

What should the new management rules be once management knows whether the rise in sales is significant? I'm afraid that in the vast majority of the cases the behavior will be exactly the same. Hence, the newly added Feature will not add value to the customer, even though some customers might ask for it and even exert a lot of pressure to have the Feature developed. Eventually, the value to the software company of developing the Feature will be negative.

Of course, for a good managerial consultant assisting in the formation of better decision processes, a specific Feature can bring immense value both to the consultant and the client. In this case, a strategic partnership between 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 customer and also have a good chance of generating revenues for the software organization is what this unique book is all about. The Agile Manifesto principle of "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" is fully in line with the Theory of Constraint's objectives. To be more precise, TOC strives to generate more of the organization's goal. But, in order to do so, the organization has to generate more value to its customers. The means of early and continuous delivery of software that truly generates value should assist both the software organization and its clients in achieving more of their respective goals.

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

--Eli Schragenheim

Read More Show Less

Introduction

Foreword

It is so good to finally have a book targeted at the software industry that challenges some of the basic business assumptions behind software engineering, and particularly those behind managing software organizations. At the time these words are written, the software business is facing huge difficulties worldwide. I hope that these difficulties also generate a willingness to look afresh at the business and to have the courage to contemplate changes. Other industries, particularly in manufacturing, went through such conceptual changes in their business processes during the 1980s and the 1990s. It is certainly 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 proud with my new package for certified public accountants. But, even though my package competed very nicely in the market, I noticed an on-going business problem: More and more development was needed to keep the package alive. In such a case, how do I justify the on-going investment? Eventually, I was not sure that a small software company, focused on a specific market niche, could be a good business--even when the product itself was enthusiastically accepted by the market. I felt that even though I already had my MBA, I needed a better perspective 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 excellent and innovative software company. It challenged some of the most sacred norms of business, such as the concept of product cost. I could not understand howanyone could challenge the basic concept that a unit of a product has a certain cost associated with it. I was intrigued enough to be open to an offer: Join Creative Output in order to develop a video game for managers that would deliver some new managerial ideas. At the time, computerized games were focused on fast fingers and perfect coordination. They were certainly not something of interest to adults. How could a computer game be readily accepted by grown-up managers and deliver new managerial ideas?

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

The relevance of the Theory of Constraints (TOC) to the software industry is twofold:

  1. Vastly improving the flow of new products to the market.
  2. Determining the real value of a proposed project, or even just a feature, to the final user. The underlying assumption is that if we know the real value to the user, it is possible to develop the right marketing and sales approach to materialize the value to the user and to the software organization.

David Anderson focuses mainly on the first aspect in this book, which includes looking at the business case and ensuring the ability to make it happen. Software organizations can definitely be improved with the help of the new generic managerial insights that have already changed traditional western industries. David does a great job in bringing together the generic managerial ideas and combining them with software-focused approaches to come up with a coherent approach on how to improve the business.

Read this book carefully with the following objective: Learn how to make more with less. Don't accept every claim David raises just because he says it is so. If you truly want to make more with less, you need to be able to internalize the claim. All I ask is you give it a chance. Dedicate time in order to rethink your environment, and then see for yourself what to do. Overcoming inertia 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 open mind and confronting new ideas that invalidate basic assumptions are what I suggest you strive for. This book is for you to struggle with. It is not trivial, and it is not a fad. If you like what you do now, it should be your responsibility to check out new ideas that might yield huge improvements.

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

A new Feature can bring value to the user only if it eliminates, or vastly reduces, an existing limitation. The amount of the value depends on the limitation removed--not on the sophistication of the feature itself. Let us take 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 good knowledge of the language, spelling mistakes are caused by writing too fast. So, without a spell checker, those people need to read carefully what they just wrote. 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 time consuming.

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 wrote before sending the document to others. People without good command of the language needed to be supported by a dictionary.

Once the limitation is vastly reduced, people should replace the old rules with new ones that take full advantage of the removal of the limitation. 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 word processor brings value. Suppose you have perfect command in the language, would you now refrain from carefully reading your recent document before sending it away? Spelling mistakes are hardly the main reason to go over any document that I want other people to read. So, for people with perfect knowledge, the spell checker offers no real value. But, for me as a person in good command of Hebrew, but not good enough in English, spelling mistakes in English are a nuisance. But, could I really avoid them just by the use of a spell checker? As long as the spell checker does not suggest how to write the word correctly--the limitation is only marginally reduced and thus not much value is produced. This means that if we want to generate significant value for the specific user group that has not mastered the language, we need to add good suggestions of what should be written instead.

In this simplified example, we already see the need to check the behavior rules both before the limitation is eliminated and after. Is it always clear what the new behavior rules should be? Assuming the user is well aware of what the new rules should be is a very common trap for too many software features.

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

What should the new management rules be once management knows whether the rise in sales is significant? I'm afraid that in the vast majority of the cases the behavior will be exactly the same. Hence, the newly added Feature will not add value to the customer, even though some customers might ask for it and even exert a lot of pressure to have the Feature developed. Eventually, the value to the software company of developing the Feature will be negative.

Of course, for a good managerial consultant assisting in the formation of better decision processes, a specific Feature can bring immense value both to the consultant and the client. In this case, a strategic partnership between 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 customer and also have a good chance of generating revenues for the software organization is what this unique book is all about. The Agile Manifesto principle of "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" is fully in line with the Theory of Constraint's objectives. To be more precise, TOC strives to generate more of the organization's goal. But, in order to do so, the organization has to generate more value to its customers. The means of early and continuous delivery of software that truly generates value should assist both the software organization and its clients in achieving more of their respective goals.

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

--Eli Schragenheim

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)