Deliver Value : 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 feel cheated. Sometimes the primary 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 vendors.

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 decisions I must make to solve my problems.

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

From Projects to Products

Custom software is often developed as a project. One of the exciting things about projects is that they tend to be funded all at once at the beginning of the project, based on the project's scope in the mind of the key decision-maker. 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, so the entire money goes to waste.

That is why we believe that product development also provides a more helpful model for Software development.

Here are the 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 signals that the scope will 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, conversely, have a beginning and (hopefully) no end. Software is more like a product than a project because the best 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 is. A value is something that the final users of the software will think is important and useful. In our industry, value has a habit of changing because customers often don’t 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 a waste; any delay that keeps customers from getting value when they want it is also a 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 software development risk lies in partially done work.

A giant form of waste in software development is “churn.” We’ve found that software development churn is always associated with extensive 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 most significant source of waste in software development is extra features. Only about 20 per cent 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 wasted.

Principle 2: Build Quality In

Once a wrong application is written, you can never convert it to perfect. However, you test and fix it. Just like you can never convert a $100 phone into an iPhone, Apple has added a quality built-in to create an iPhone. 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 it's OK just because a defect is in a queue; 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. The ultimate goal is to eliminate the defect-tracking queue.

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 defects get reduced mainly.

Principle 3: Create Knowledge

Software development is a process of turning knowledge into a software system. If the knowledge is insufficient, the resulting system can never be sound. All the money can go to 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 before 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 the wrong system and what happens in the traditional waterfall process.

In waterfall, a good project is defined early, planned in time, executed and delivered on time. But in most cases, the sound projects score poorly in quality, productivity, and market acceptance, while the “bad” project, done on an agile basis, becomes a market success. Unsurprisingly, the team that learned from the market throughout development created a better product. It is essential to have a development process that encourages systematic learning throughout the development cycle, but we also need to improve that development process systematically. 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 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, the last chance to decide 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 quickly 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 aimed explicitly at leaving options open so that irreversible decisions can be made as late as possible.

Principle 5: Deliver Fast

In software development, slow delivery is sometimes the root of most problems. It simply kills the feedback loop and simply paralyses the knowledge creation process. Once something is delayed, it does not stay at 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 an extensive software, the top 20% of essential 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 based on time often have a significant cost advantage over their competitors: They have eliminated considerable waste that costs money. In addition, they have meagre 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.

Notably, 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 ensures 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. Companies that buy all the expertise they need will also find that their competitors can buy it. Companies that see no need for expertise will find that they have no sustainable competitive advantage. Wise companies ensure 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 sub-optimize. •

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: The complexity of the code base increases.
Result: The 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 receiving an order to addressing a customer need until the software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, we can guarantee that the overall value stream will suffer.