Deliver Value not Code - 7 Principles of Lean Software Development

As a customer of  any product or service we always have preoccupied basic expectations from our vendors. Most of the time we do not express everything unless asked, but if those are not delivered, we just feel cheated. Sometimes the basic purpose of the objective is not fulfilled and in most cases the product becomes valueless. The credibility of the provider gets reduced or sometimes lost. These are so serious, we sometimes think about switching the vendor.  

 If we try to jot down these basic expectations these are most of the time ..
 

1. It will solve my problem completely.
2. It will not waste my time.
3. It will provide exactly what I want.
4. It will deliver value exactly where I want it.
5. It will supply value exactly when I want it.
6. It will reduce the number of decisions I must make to solve my problems.

Absence of one point can make the product useless or atleast annoy us deeply. So any product developer or service provider must think of these 6 points. A software application is no exception, if as a software vendor, fail to bundle these values with our application, we will simply lose trust from our clients and final users.

From Projects to Products

Custom software is often developed as a project. One of the interesting things about projects is that they tend to be funded all at once at the beginning of the project, on the basis of the scope of the project in mind of the key decision makers. And  the success of the project is measured based on whether or not the cost, schedule, and scope commitments are met.

Project : Start->Completion ->Maintenance

However there is every chance the project is done as per plan but it  fails to satisfy the final users and so entire money goes in waste.

That is why we believe that product development provides a more useful model for Software development too.

Here are steps of product development.

Product: Concept -> Feasibility -> Internal Release -> Alpha release -> Beta release -> First Production Release -> DOT upgrade -> Major Release

Products, on the other hand, are typically funded incrementally. This incremental funding is a clear signal to all that the scope is expected to evolve as knowledge is gained. The success of product development is generally measured based on the market share and profitability that the product eventually achieves.
There are other differences between projects and products. Projects have a beginning and (apparently) an end. Products, on the other hand, have a beginning and (hopefully) no end. Software is much more like a product than a project, because most good software lives on and changes for a long time.

Lean Software Development Principles

Principle 1: Eliminate Waste

To eliminate waste, you first have to recognize it. Since waste is anything that does not add value, the first step to eliminating waste is to develop a keen sense of what value really is. A value is something that the final users of the software will think are important and useful. In our industry, value has a habit of changing because, quite often, customers don’t really know what they want.

Waste is anything that interferes with giving customers what they value at the time and place where it will provide the most value. Anything we do that does not add customer value is waste, and any delay that keeps customers from getting value when they want it is also waste.

In manufacturing, inventory is waste. The inventory of software development is partially done works. Partially done software has all of the evils of manufacturing inventory: It gets lost, grows obsolete, hides quality problems, and ties up money. Moreover, much of the risk of software development lies in partially done work.

A big form of waste in software development is “churn.”  We’ve found that software development churn is always associated with large inventories of partially done work. When requirements are specified long before coding, of course they change. When testing occurs long after coding, test-and-fix churn is inevitable.

But far and away the biggest source of waste in software development is extra features. Only about 20 percent of the features and functions in typical custom software are used regularly. Approx 80% of the features in typical custom software are rarely used. They add complexity to the code base that will drive up its cost at an alarming rate, making it more and more expensive to maintain, dramatically reducing its useful life. Most of them are practically waste.

Principle 2: Build Quality In

Once a bad application is written, you can never convert it to a perfect one, however you test and fix it. Just like you can never convert a $100 phone into an iPhone, to create an iPhone Apple has added a quality built-in. So your target should never be putting defects into a tracking system, rather you avoid creating defects in the first place. There are two kinds of inspection: inspection after defects occur and inspection to prevent defects. If you really want quality, you don’t inspect after the fact, you control conditions so as not to allow defects in the first place.

Defect tracking systems are queues of partially done work, queues of rework if you will. Too often we think that just because a defect is in a queue, it’s OK, we won’t lose track of it. But in the lean paradigm, queues are collection points for waste. The goal is to have no defects in the queue, in fact, the ultimate goal is to eliminate the defect tracking queue altogether.

TDD (Test Driven Development) is a proven technique to add built-in-quality to your software. In traditional waterfall development requirements test cases are written after  the development has started. So developers are given the option to make defects. But in TDD, all requirements logic (if missed they are likely to create a defect) are written in terms of Test Cases before the development. And the test cases are tested by the development team itself (testers are also part of the development team) so the chances of the defects get largely reduced.

Principle 3: Create Knowledge

Software development is a process of turning knowledge into a software system. If the knowledge is bad, the resulting system can never be good. The entire money can go in waste.

One of the puzzling aspects of “waterfall” development is  the  knowledge, created before coding and kept separated from coding. Software development is a knowledge-creating process. While an overall architectural concept will be sketched out prior to coding, the validation of that architecture comes as the code is being written. In practice, the detailed design of software always occurs during coding, even if a detailed design document was written ahead of time. So if the knowledge is not created during the coding process, there is a 100% chance that the developers will develop a wrong system and what actually happens in the traditional waterfall process.

In waterfall a good project is that which is defined early, planned in time, executed and delivered on time. But in most cases the good projects score  poorly in quality, productivity, and market acceptance while the “bad” project, which is done on an agile basis, becomes a market success. It’s not surprising that the team that learned from the market throughout development created a better product. It is important to have a development process that encourages systematic learning throughout the development cycle, but we also need to systematically improve that development process. A lean organization knows that it must constantly improve its processes because in a complex environment there will always be problems.

Principle 4: Defer Commitment

During development, some decisions on deciding the software knowledge are irreversible. In case we miss it, we miss it forever. So during the knowledge creation process, schedule irreversible decisions for the last responsible moment, that is, the last chance to make the decision before it is too late. This is not to say that all decisions should be deferred. First and foremost, we should try to make most decisions reversible, so they can be made and then easily changed.

One of the more useful goals of iterative development is to move from “analysis paralysis” to getting something concrete accomplished. But while we are developing the early features of a system, we should avoid making decisions that will lock in a critical design decision that will be difficult to change. A software system doesn’t need complete flexibility, but it does need to maintain options at the points where change is likely to occur. Best software design strategies are specifically aimed at leaving options open so that irreversible decisions can be made as late as possible.

Principle 5: Deliver Fast

In software development slow delivery sometimes is the root of most of the problems. It simply kills the feedback loop and simply paralyses the  knowledge creation process. Once something is delayed, it does not stay in the top of the mind of the stakeholders or product owner, hence when any feedback is required, it requires relearning - and in most cases wrong feedback is passed. If it is a large software, at first top 20% important features should be chosen in the first MVP, architecture should be built keeping the whole thing in mind, then further divided into independently testable chunks and then delivered one by one.

Companies that compete on the basis of time often have a significant cost advantage over their competitors: They have eliminated a huge amount of waste, and waste costs money. In addition, they have extremely low defect rates. Repeatable and reliable speed is impossible without superb quality. Furthermore they develop a deep customer understanding. They are so fast that they can afford to take an experimental approach to product development, trying new ideas and learning what works.

Principle 6: Respect People

Respect People means in software development from the point of view of the people doing the work.

It’s noteworthy that three of the four cornerstones of the Toyota Product Development System are the people involved in the product development process. Looking at these three cornerstones gives us a broader idea of what respecting people means:

1. Entrepreneurial Leader: People like to work on successful products, and highly successful products can usually be traced to excellent leaders. A company that respects its people develops good leaders and makes sure that teams have the kind of leadership that fosters engaged, thinking people and focuses their efforts on creating a great product.

2. Expert Technical Workforce: Any company that expects to maintain a competitive advantage in a specific area must develop and nurture technical expertise in that area. Companies that buy all the expertise they need will find that their competitors can buy it also. Companies that see no need for expertise will find that they have no sustainable competitive advantage. Wise companies make sure that appropriate technical expertise is nurtured and teams are staffed with the needed expertise to accomplish their goals.

3. Responsibility-Based Planning and Control: Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals. Respect means that instead of telling people what to do and how to do it, you develop a reflexive organization where people use their heads and figure this out for themselves.

Principle 7: Optimize the Whole

Software development is legendary for its tendency to suboptimize. •

Vicious Circle No. 1 (of course, this would never happen at your company):

A customer wants some new features, “yesterday.”  Developers hear: Get it done fast, at all costs!  Result: Sloppy changes are made to the code base.  

Result: Complexity of the code base increases.  
Result: Number of defects in the code base increases.  
Result: There is an exponential increase in time to add features.

Vicious Circle No. 2 (and this wouldn’t happen at your company either):  

Testing is overloaded with work.  
Result: Testing occurs long after coding.   
Result: Developers don’t get immediate feedback.  
Result: Developers create more defects.
Result: Testing has more work. Systems have more defects.  
Result: Feedback to developers is delayed further. Repeat cycle.

A lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, we can just about guarantee that the overall value stream will suffer.