Category Archives: Lean

Hard work is killing people. Literally!

Recently, I was reading an article on how Japanese-style manufacturing isn’t working out quite so well in India (despite having been successfully around since 80s), and that there have been several strifes lately. There was an interesting reference to what the Japanese call as Karoshi and Karojisatsu. Now, unlike many other Japanese words, these are really gross words because they mean

  • Karoshi = Death from Overwork
  • Karojisatsu = Suicide from Overwork (and stressful working conditions)

Curious to know more about it, I chanced upon this graphic from ILO page on workplace safety:

Karoshi and Karojisatsu cases in Japan, 1997-2011, ILO This data comes from Japan, and while the numbers might not (yet!) look staggering to many a folks, the trend is unquestionably disturbing, and our own deniability might only be getting compounded by lack of data from our own respective countries or industries, not to mention the social stigma that might be associated with someone refusing to ‘work hard’ on medical grounds lest they suffer an injury, suffer a burnout or commit suicide!

In the last few years, I have heard of small but increasing number of such sudden deaths among senior IT professionals – not just in Bangalore, but also globally. You can read about them here, here, here, and here.

Burnout is a serious issue for several countries, industries and people, even if we don’t acknowledge in as many words. In our industry, where heroism, cowboy programming and all-nighters are considered cool and an integral part of the software subculture, there has been a (really) small effort to address work-life balance by identifying that software development should be ably to proceed “indefinitely” on “sustainable pace” with XP explicitly advocating 40hrs a week (though some might disagree with this interpretation of “sustainable pace“). However, anyone who has ever done any non-trivial piece of software development will point out how hollow this expectation is in reality. When it is the release time, families learn to deal with their family members coming late or staying back office overnight, or working through the night even if home. Those in startup phase don’t have the luxury of ‘closing the day’, and those who are entrepreneurs actually thrive in such environment. So, is the thrill-seeking behavior at work here? Could it even be the case that we are only unknowingly aggravating the problem by hiring more people who think, talk and work like us – thereby creating a tarpit-kind of environment where there is no escaping it?

It is well-known in manufacturing that we never utilize machines more than 80-90% of their rated capacity (global stats on utilization are more like 80%). And yet, we don’t think twice before ‘loading’ human beings to much beyond their 100% capacity! Unfortunately, the data suggests that working more reduces productivity, as below:

Working hours vs. Productivity

Or, our ‘professionalism’ stops us from admitting that if I put out my case for a better work-life balance, I might be considered a loser and be considered unfavorably in appraisals, promotions and salary raises?  

So, how do you deal with it, or rather, ensure that you don’t get burnt out? Or, if you are a people manager or a leader, how do you ensure those supporting you are not getting burnt out?

Important to call out here that the old harmless joke “Hard work never killed anyone. But, why take chances?” suddenly doesn’t look so innocuous anymore. 

Worth thinking…

Why user stories make sense?

User story is a popular mechanism used by most agile methodologies to communicate user requirements. Actually, this is only partially true. User stories are meant to be a placeholder to initiate an early conversation between the product owner and the team on key hypotheses so that a quick validation of them could be done to refine/confirm/reject our understanding of what the customer really wants. To that end, user stories are not anything like the requirements of yesterday – they are not even remotely meant to be complete/comprehensive and so on. 

The reason user stories (and not ‘well-formed’ requirements, if that is ever possible) makes sense is because we human beings are not experts in following the written word, and are likely to misinterpret requirements even when they are explicitly written down, especially when the communication is a one-time event and not an ongoing process. (if you don’t believe this, just visit this interesting site that celebrates real-life examples of how something as simple as icing on the cake can go horribly wrong despite really simple and absolutely clear instructions!). And we are talking about building complex mission-critical systems that must operate 24/7 with top speed and efficiency. If only the written word could be consistently understood by the receiver as intended by its author… 

On the other hand, if there is a continuous two-way dialog between the product owner and the agile team, such purposeful brevity leads to curiosity which then leads to a constantly improving and better shared understanding that refines as the product gets developed incrementally and gets periodic user feedback. 

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer's wants and needs.

User stories reflect the reality that we might not have 100% clarity about the requirements on day one, but with constant dialog, we might be able to improve our shared understanding of customer’s wants and needs.

The key benefit of user stories is that instead of waiting for weeks (even months!) to get a fully-bloated and rather unprioritized PRD which is supposed to have fully-baked requirements while the development team sits idle all this time, is that identifying highest priority user stories and using them  to develop a prioritized product backlog allows the teams to get started much earlier and start developing features which could then be put out in front of customers to get real feedback (as opposed to individual ‘opinions’ that might/not best guide us in an uncertain environment). This is especially important because in the past, when the world was little less complex and much more underserved. I purposefully use this term ‘underserved’ because it is not that people have suddenly become much more demanding about what they like or not, but were just told there were exactly three carmakers to choose from, or just two operating systems to choose from, and so on. However, with rapid advancement of computing paradigms and constantly lowering cost of ubiquitous communication devices, they suddenly have the opportunity to demand what they want, and hence classical ‘forecast’ models of requirements elicitation, design or production (at least in the manufacturing sense) don’t work so effectively as much as the newer ‘feedback’ driven models that allow for developing key hypotheses (and not hard requirements carved in stone) which could then be quickly and cheaply delivered as ‘done’ features so that customers could tell us if they like them or not. Based on such valuable customer feedback, the team could iterate to either refine the feature, or to pivot, as the case might be. In the past, this might take the entire product gestation cycle, by which time, many, if not most, things might have undergone significant changes, and the entire development costs being sunk by that time, not to mention complete loss of any window of opportunity.

As Facebook says – Done is better than perfect. User stories allows developing a small slice of the product without really perfecting the entire product, but facilitates the process of validated learning that eventually helps develop a product with much higher chances of meeting customer needs.

In today’s world, you probably might not have the luxury of having investors wait multiple years for an exit, or customer waiting several quarters for a perfect product when the competition is willing to serve them faster (even letting them lay their hands on an earlier version and give feedback thus making customers a co-creator of the product), or employees working month after month without getting any meaningful feedback from customers. And we know that absence of any feedback eventually leads to erosion of trust. Incremental product development could help you bridge such trust deficit by delivering highest value to customers early and periodically, and user stories might help you get your project a quickstart.

How Lean thinking improves productivity in software teams?

At its core, productivity for a software team (often wrongly termed as programming productivity because software development is much more than mere programming) looks like a great idea. In its simplest form, it compares output of the team (amount of useful and usable software created, amount of unnecessary rework done, number of defects produced, etc.) to the input (time, effort and resources invested in producing software) factored-in by the uniqueness of the given software  endeavor and other external environmental factors (complexity of the software being produced, impact due to team sizes, nature of team spread and its familiarity with the problem at hand, problem domain, and so on). Unless you are willing to discount software development as a non-business critical activity undertaken purely for the labor of love that should not be ‘measured’ lest it dilutes the very ethos of software development as a creative cognitive endeavor, one might agree, albeit reluctantly, that some measure of how well we are doing is clearly in order. Can you think of a single business activity where such a measure should not be done?

In last few decades, researchers and statisticians have tried to create quantitative measures of productivity. However, due to an often unilaterally percieved inherent ‘uniqueness’ of every software endeavor, practitioners have consistently rejected such measures contending that there are either far too many assumptions in its definition and far too many variations in practice, or both. Instead of focusing on the ‘vital few’ commonalities, it is only unfortunate that practitioners have virtually rejected productivity measures in all forms by considering the ‘trivial many’ differences. What could have gained the industry by considering a big-grain definition of productivity was unfortunately lost because of focusing on decimal-digit precision of productivity measures.

In this blog, I will discuss the subject of productivity from a conceptual plane, and explore how Lean thinking helps us understand it little better by establishing a correlation between wastes in software development and productivity of the team. Lean thinking is much more than identification and elimination of the seven types of wastes, but I will only take up the issue of wastes in this blog.

In the simplest form, we can call a process or an activity productive if it creates an output higher than its input. Though the input and output are often in two different and inequitable currencies, we are still mostly able to compare them. What that means at a conceptual level is that:

  • If Output < Input, we can say that the productivity is low
  • If Output > Input, we can say that the productuvuty is high
  • If rework is high, we can say that the productivity is low
  • If rework is low, we can say that the productivity is high 

These are highly generic views of productivity that most of us understand, but unfortunately they are not very usable to understand the factors that impact an output to become low, or the rework to become high. Developers might give one view, and testers might give another view as to why the output is low. There is no common vocabulary that can explain at a fundamental level what is it that is causing the productivity to dip. Context-specific variations (like differences in programming environment, percieved differences in complexities, developer competency, tester efficiency, etc.) might be too many to be usable to form any meaningful conclusions.

Lean thinking offers a more specific understanding into the wastes that typically make a process costlier (in terms of time or effort or both) than what it ought to be. Lean identifies seven types of wastes in a manufacturing setup. These wastes are known to introduce avoidable wastes, and Toyota pioneered a production system and an organizational culture that seeks to sysmetically eliminate root causes behind these wastes. Software practitioners, led by Mary and Tom Poppendieck, have investigated borrowing from Lean thinking into software development in last couple of years. Let’s examine how Lean encourages eliminations of following seven types of wastes in software development, and how they individually impact productivity of a team:

  1. Overproduction: Implementing a feature is an irreversible decision that takes lots of time and effort from the product engineering team, and delivery of a feature must wait until the next release cycle (whether the big-bang release in conventional software development, or the next real shippable release in agile development). If there are extra features in a software that remain unused because they are not of high priority but the engineering team is anyway spending effort to develop and test it, it is probably lowering the productivity of the team that could have used its effort elsewhere to develop other important features. The customer is also not benefiting from such overproduction of features, because he not only must wait for the desired features to be delivered, he must also pay the delivery team for those unimportant features that are not being used.
  2. Inventory: Anything that has not yet been delivered to the customer is work-in-progress (WIP) or inventory. The higher the inventory in a system, the higher is the number of resources locked-up and unavailable for any other activity. Even the work that has been completed but still sitting on the shelf is an inventory that is not creating any tangible value either to the team or the customer. If there are too many requirements yet to be implemented, it involves doing requirements analysis, design, development and testing without any of that effort being delivered to the customer, and hence increasing the work in progress and thus lowering the productivity at a business level. Even if a critical feature has beem completed, but it waiting simply because several other not-so-important features must be included alongwith in the next release, it is also adding to inventory because that important feature is not immediately delivered to the customer.
  3. Extra Processing: If the software is implemented in a complex manner that requires extra processing (e.g., a design that requires more storage, or duplicates data or code needlessly, etc.), it is either increasing the effort required to develop and test the software, or increasing the usability complexity, or both. Either ways, it is lowering the productivity. However, the opposite of extra processing is not smart programming, which might solve the problem in short run, but create maintenance problems in the long run.
  4. Motion: If the information is not readily available to the engineer, he/she has to spend unnecessary and avoidable time and effort that it takes to fetch the required information (which could anything – clarification about requirements, latest design specs, or locating the correct module from another team for integration, etc.), thus effectively lowering the productivity.
  5. Defects: Any defect that is passed on to the customers requires the engineering team to once again open up the code and spend effort to fix the problem. Since no new output is generated in this process, and the only output is fixing the functionality that should not have been broken in the first place, the net productivity over the entire product engineering lifecycle gets impacted adversely.
  6. Waiting: Perhaps no other project resource is as irrecoverable as lost time. Brooke’s Law reminds us how difficult, if not impossible, it is to recover delay from a project. Waiting for any resource for any reason creates unpredictability in software development apart from creating activities of zero or low output, which again reduces the productivity.
  7. Transportation: Handoffs are perhaps a Fordism legacy to the waterfall development where a team of business analysts would complete their work in isolation and handover the specs to dev team. Dev teams in turn would work in isolation and pass on the software to test team for testing, and so on. If all these teams are working in silos, such practice of working in isolation would often result in information distortion (or loss) down the stream, which could result in missed requirements, misunderstood requirements, unclear design, and so on. All these will eventually require extra (and unplanned) effort to implement the right functionality or fix the broken functionality, thus lowering net productivity over the entire engineering lifecycle.


As we can see, analyzing wastes in software development using the Lean thinking provides us a technology-independent and function-neutral view of the inefficiencies of the software process that can be used to achieve substantial improvements in productivity of the teams. None of these ‘attack’ an individual for lower productivity, and only look at the systemic deficiencies that must be eliminated for a team to perform at higher level.  However, of what possible business value would be the process of elimination of such wastes if we can’t picture ‘before’ and ‘after’ ? It is extremely important to assess the state before and after introducing a change – how else do we know if our efforts are yielding the desired results ? So, measuring the productivity in some absolute numbers is like the feedback whether an improvement is happening in the right direction (or not).

Lean thinking or not, do you measure productivity of your software teams? If yes, what for, and if not, why not?

Toyota’s Wisdom for Tomorrow’s Managers…published

In one of my previous posts, I had talked about an article I wrote for business review magazine. It got published in the Dec 2008 issue. The article discusses following ten ‘wisdoms’ from Toyota for its managers:

  1. Open the Window. It’s a big world out there !
  2. Make the most sincere efforts in your assigned position
  3. Taking on challenges is the way to gain experience
  4. Be an Innovative and Creative Thinker

  5. More uncertain the future, more important to have courage

  6. If a problem is left unsolved and the superior is uninformed, neither Kaizen nor cost reduction can be applied

  7. Unless we establish a unique pattern of control and organization, no amount of financial resources will be sufficient

  8. Eliminate muda, mura, muri completely 

  9. Ask ‘Why’ five times about every matter

  10. Trust is key

You can read the article here. 

What is a Lean Enterprise ?


A Lean Enterprise is defined as “a business system for organizing and managing product development, operations, suppliers, and customer relations. Business and other organizations use lean principles, practices, and tools to create precise customer value—goods and services with higher quality and fewer defects—with less human effort, less space, less capital, and less time than the traditional system of mass production.”[1]

Womack and Jones describe Lean Enterprise in detail as follows[2]:

“The objectives for the lean enterprise are very simple: Correctly specify value for the customer, avoiding the normal tendency for each firm along the stream to define value differently to favor its own role in providing it. …Then identify all the actions required to bring a product from concept to launch, from order to delivery, and from raw material into the hands of the customer and on through its useful life. Next, remove any actions which do not create value and make those actions which do create value proceed in continuous flow as pulled by the customer. Finally, analyze the results and start the evaluation process over again. Continue this cycle for the life of the product or product family as a normal part, indeed the core activity, of “management”.

The mechanism of the lean enterprise is also very simple: a conference of all the firms along the stream, assisted by technical staff from “lean functions” in the participating firms, to periodically conduct rapid analyses and then take fast-strike improvements actions. Clearly someone must be the leader, and this is logically the firm bringing all of the designs and components together into a complete product…However, the participants must treat each other as equals, with muda as the joint enemy.”

How does one create a Lean Enterprise ? How does that happen in a software organization ? Let’s explore this subject in the coming few weeks…

1. What is Lean,

2. Lean Thinking, Womack and Jones, pg 276

How do you manage a Disruption ?


The world of new product development is (NPD) is an extremely challenging one, and while the output of such an endeavor is never a sureshot guarantee, the journey itself is immensely fulfilling. Edison was reportedly asked by his assistant on not being successful with his electric bulb work despite two years of efforts, something that Edison could not understand… “what failure…we have discovered so many ways how an electric bulb won’t work”.  In a corporate context, however, we all must work within boundaries of finite resources (time, resources, people, etc.) to create the next telephone, the next microwave, the next LCD television, the next Windows or the next Google. It is perhaps the dream of every professional to be part of such life-altering Greenfield projects (many times also referred to as the ‘Version One’ in software world) and make a lasting impact on world around us.

However, innovation doesn’t only happen in such large doses. It also happens in small doses: small-small daily changes, enhancements, modifications, improvements done in thousands and millions of places in a product such that the final impact is as breathtaking as the version one. In fact, some might consider such ‘brownfield’ effort as much, or even more, challenging than the Greenfield because in a brownfield effort, one must work around constraints and ground realities that are not up for change. Irrespective, there are adequate challenges and learning opportunities in any endeavor that creates, or improves upon an existing product or service. This is the opportunity for a technical professional to sometimes work as an artist and make her lasting impression on the canvas, while also working as a child building grand designs of lego building blocks. As a manager, the fun is little more challenging than for others J

While a traditional project manager applies all his knowledge and skills to synthesize all tasks, inputs, resources and constraints to build a plan to execute the project, a project manager working on a new product development endeavor must recognize that the work has innate challenges, and quite often the task is a wicked problem.  There is an element of risk, a certain amount of discovery that in fact makes working on such a project worthwhile. It is not by accident that the best talent in the world gets drawn to companies that routinely engage in such work. Welcome to the world where the only objective is to create disruption ! However, traditional project management is all about applying time-tested sound principles and practices to bring a project under control and achieve all its goals. However, managing a disruptive endeavor is much more than that – to begin with, not all goals might be known. Some risks might be completely immitigable, and one must simply learn to accept them. Many of the activities in an NPD project might actually be undertaken for the first time, and hence for all practical purposes is more of research work than a mere development.  In short, one might not be able to apply all practices of traditional project management in letter and spirit and yet be able to create the right disruption that is envisaged. However, it is not an impossible problem.

In PMI NPDSIG, we are working towards creating a community of researchers and practitioners and enrich the body of knowledge by learning newer and innovative methods of problem-solving, shortening the cycle times, improving product reliability, improving the ability to manage such a project and so on. While recognizing the inherent challenges such an endeavor poses, and to an extent might be at crossroads with a very straightjacket approach to project management, we strive to explore the middle path – how best to apply principles of project management to a new product development endeavor, and meet the dual objectives.

I am part of the NPDSIG team for 2009, and as Vice Chair for Communications, I have an extremely interesting and challenging role. Here is how I propose to work on them:

  • PMI NPDSIG publishes a newsletter, Project Management Innovations, for which I serve as the editor. It is published electronically four times a year. I propose to take up themes for each of those issues and scout for talent all over the world to share their opinion, experiences and trends in that area. The idea is to learn from different fields and understand how well practices from one area could be used to solve similar-looking problems in another. Some of the themes I am exploring are
  • Lean: how well Toyota’s Lean Production System is being used in creating other innovative products and services
  • Green: we often tend to associate green only with companies that consume hydrocarbons, but in a broader sense, several companies are making invaluable contributions by adopting green in their technologies
  • Innovation: while our field of work is all about innovation, how the process of innovation is managed, how are organizations able to reduce the risks and lead times, etc.
  • Human: we exist to serve the society, and so must our products. How do organizations create technologies that, for example, enable the poorest of the poor to become literates, acquire practical skills to earn a livelihood and become self-sufficient, how has mobile telephony changed the lives of millions of poor people around the world and empowered them as a first-class citizen of this world.

As an editor, I shall be working with potential authors and SIG administrator on planning the release, review and proof-read articles, etc.

  • The discussion list has over 900 members, but there is practically no activity on that list. We need to revive it by involving list members in various discussions, share thoughts and articles, etc. While this requires a team effort, the need is to identify subject experts who can initiate conversations, offer conflicting opinions, cross-pollinate ideas and involve list members by listening to their problems, their experiences. The idea is not to take the high road by proclaiming ourselves as ‘experts’ but by facilitating thought process, we aim to serve the listmembers.
  • I would like to conduct one or two events in 2009 with PMI Bangalore Chapter and also with IEEE Technology Management Council (TMC) Bangalore chapter of which, I am the Chair for 2009. IEEE celebrates 125th anniversary in 2009 and among eight global cities, Bangalore is chosen as one of them and will have major events ( I propose to conduct some event along with IEEE TMC Bangalore chapter that helps us build bridges within IEEE community as well as (hopefully) open doors for more membership. I don’t know if that is possible, and if yes, what would be a budget for this, but I thought of sharing my thoughts here so that you could advise on what is possible.
  • On the lines of PDMA and our very own PMBoK, I would like our team to undertake an effort to codify the NPD knowledge in context of project management profession. This codification could also be a reflection of the state of art in this field, and serves as a quick-learning tool into the basic tenets of NPD, tools and resources, best practices and emerging trends. This could be made freely available resource for the advancement of our field.

If you are a professional involved in the exciting world of new product development, then join us for mutual learning.

Toyota’s Wisdom for Tomorrow’s Managers


I just completed first draft of this paper for business review magazine of a city college of business administration. If it gets selected for publication, you will get to read the full paper on this site :). Here is the abstract:

Toyota’s pioneering work in automobile production systems continues to be among the most profound and radical departure from conventional thinking since the times of Henry Ford, and has led to unprecedented cost efficiencies and quality improvements for them. For long, it was thought to be a Japanese expertise – one that could not be duplicated by non-Japanese people, or outside Japan. However, subsequent to Womack and Jones’ pioneering works, “The Machine that Changed the World” and “Lean Thinking”, it has not only been adopted outside Japan, its universal principles are also finding huge acceptance in other sectors and service industries throughout the world.

However, any process is only as good as the people involved in it and their thought process behind it. Toyota’s production system is not only about how the production flow is organized – it includes fundamental aspects of professional ethics and work culture that are deeply ingrained in their thinking. These so-called “Toyota Traditions” serve as the guiding light for managers and employees alike and continue to remain relevant as ever. They also are ubiquitously applicable in almost every stream of management.

It is this author’s firm belief that by merely adapting Toyota’s Lean Production System, one can’t transform a normal organization to a Lean Enterprise. Alongside the changes in process, one must pay adequate attention to adapting the mindset behind Lean culture as well. With that context, I have analyzed and interpreted some of the Toyota’s Traditions that are most relevant in context of tomorrow’s manager in this paper.

Stay tuned for updates on this.

This is the festival season, and kids have holidays. I am also off to a short holiday. Festival greetings, and enjoy the winter holidays. See you soon. 

What is the Inventory of your Software Development project ?


Traditional software development follows a quintessential Waterfall model. Among its many limitations, originally discussed by Winston Royce in his 1970 classic paper “Managing the Development of Large Software Systems” and many more thereafter, it also forces a build-up of ‘work-in progress’, or inventory of unfinished work that has not yet been delivered to the customer, and even if it has been presented to the customer, it doesn’t add value until the final working software has been delivered. I define ‘value’ here as originally defined by Womack and Jones in their classic ‘Lean Thinking’, “…The critical starting point for lean thinking is value. Value can only be defined by the ultimate customer. And it’s only meaningful when expressed in terms of a specific product (a good or a service, and often both at once), which meets the customer’s needs at a specific price at a specific time”.  


Agile software development, as originally envisaged in the Agile Manifesto, aims to address several of the challenges faced in a Waterfall-type of software development by working on shorter delivery cycles using only a subset of requirements at a time. This subset of requirements (“Sprint Backlog” in Scrum) is prioritized by the customer or customer’s representative (“Product Owner”), so at the end of this short delivery cycle (“Sprint”), the customer gets ‘potentially shippable software’ having exactly those features that add ‘value’ to her. Frequent delivery of working software also has an additional impact on reducing ‘inventory’ levels in a software project, however, Agile doesn’t specifically address how is improves it over traditional software development. We can use concepts from Lean manufacturing to understand and explain inventory build-up in a software development, and how Agile practices help us manage them better compared to the traditional software development practices.


Little’s Law states that inventory in a process is the multiplication of throughput and the flow-time. In traditional manufacturing, there is a strong emphasis on plant capacity utilization as a core driver in cost management. However, a high plant capacity utilization requires (or rather leads to) high inventory to ensure the production doesn’t slow down for want of raw materials. High inventory in turn leads to a low inventory turnover, signifying poor sales, thus having high economic implications. Inventory is also identified as one of the seven wastes in Lean. I have discussed the concept of inventory in a typical manufacturing process and how Little’s Law can be used to analyze mathematical relationship between inventory, manufacturing lead time and cycle time in my article “Applying Little’s Law to Agile Project Management – part 1”.


In software development, inventory can be thought of as the development costs that continue to be incurred while the development activities are underway. Only when a successful delivery has been made and accepted by the customer, the development team can realize its developments costs, and free-up the ‘inventory’. Until such time, this ‘inventory’ accumulates and remains locked-up.


In traditional software development, there is no concept of interim releases to the customer. Some teams might provision for a proof of concept or a prototype, but most often, they are only meant to work under ‘test conditions’, meaning they are not fit for deployment in real world. At best, they give a feel of what it likely to come out of the development lab at the end of a generally long development cycle. In that long cycle, it is possible that some requirements become obsolete, or get clubbed with some other requirements, or just get de-prioritized. In effect, a ‘BRUF’ approach often might end up the team with a software built to original specs, but unfortunately for them, the customer’s view of the world has changed while they were busy developing the software in isolation. So, the ‘effort’ that doesn’t add to ‘value’ also becomes part of an already bloated inventory of development costs. Mary and Tom Poppendieck have discussed the subject of ‘inventory’ in software development in great details in their seminal work on Lean Software Development. They have taken a much wider view of the inventory, while I have limited my discussion in this article only to the development costs.


When we use Agile practices, we work on a prioritized subset of requirements for each increment, and at the end of each such increment, we deliver a working software (not a prototype) to the customer. The customer is in immediate position to test-drive the delivery and come back what any necessary changes that could be incorporated in the very next increment. At the end of each such successful increment that delivers ‘value’ to the customer, it is possible for the development teams to realize their development costs, thereby resetting the inventory levels to zero before starting the next increment. I have discussed this scenario taking a near-real-life example in my featured paper “Applying Little’s Law to Agile Project Management – part 2”.



Agile software development is a radical approach to improve productivity in software development teams while improving the value delivered to the customer by using shorter delivery cycles (and a lot of engineering practices, though not discussed in this article). Using Agile practices, it is possible for the development organization to create ‘value’ for the customer and also manage its own inventory levels. This is true for ISVs, or services companies working for a customer. It is also equally applicable for start-ups that often work for a prolonged gestation period in a ‘stealth mode’ and their only performance metric during that phase being the notorious ‘cash burn rate’. In today’s tough economic times, virtually every firm is trying to reduce its cash cycles, and Agile software development just provides one more financial incentive by reducing the inventory and shortening the cash cycle.