3 Lean Principles for Requirements Management & Testing

This article originally appeared on Konsultbolag1

Essentially, the goal of the lean approach is that every employee’s every activity is linked to customer value. Anything else is waste and should be eliminated. Lean first emerged in product development in the Japanese automotive industry and has been adapted in ever widening circles ever since.

The Agile movement in system development borrowed its basic principles from the Lean philosophy. Some examples of agile principles from Lean include customer focus, timely delivery, and openness to late-stage changes.

Customer value is at the core of the lean philosophy. All around the world, “Lean IT” is becoming common parlance. But what does it really mean? And what does it mean for us, developers and testers?

Three Lean Principles:

Well, three basic principles of Lean production apply directly to system development:

1. Eliminate waste
2. Deliver fast
3. Defer commitment

Let’s see these three lean principles in a bit more detail:


1: Eliminate waste

The worst form of waste in system development is almost certainly redundant, unnecessary features. Let me give you a personal example. I was once involved in implementing an order management system for a client in Sweden. The standard software contained a telesales module with a “call list” function that was originally built for a U.S. customer. The Swedish client had never worked with call lists, so we spent a huge amount of project time getting a grasp on how the function worked and determining requirements for our client-specific implementation. After several rounds of revising requirements, implementing, reviewing, and fixing, we finally completed the module.

Much to our disbelief, however, the client’s processes had no pressing need for call lists, and had no intention to start using them soon anyway, so we never deployed the call list module in production. Our next project? Yanking out everything deemed unnecessary in the system, including the call lists.

In this case, the call list function was a clear example of “waste”. It provided zero value to the client, but caused significant costs in terms of training, requirements definition, testing and correction — time that should have been spent on something the client actually wanted instead.

If you agree that the two main objectives of testing are to 1) verify and find errors and 2) validate that the client benefits from the system, you can draw the following conclusion regarding Lean: Validation is far more important than verification.Obviously, you do still have to verify the software and find defects, but if the function you’re testing doesn’t provide direct value to the client, all the time you put into it is just waste. So your top priority in requirements management and testing work has to be customer value!


2: Deliver fast

The agile revolution has its roots in the Lean principle of “Deliver fast”. Thanks to methods like Scrum and XP, short iterations are common in software development today. This is not just about fancy words, it’s also a fundamental shift in mindset. Agile system development methods appeal primarily to developers, even if they do focus on clients and customers. You could actually forget clients and only think about developers when you think about Scrum, but Lean describes the same basic principles in a language that inherently includes clients and customers.

Development iterations according to Lean concepts immediately demonstrate that it is less development-focused and more customer-focused than Agile alone. As an example, in Lean you use the concept of “feedback” rather than “testing”. Testing is merely a development activity aimed at getting feedback. More importantly, you use the term “improvement” instead of “correction”. If you work sequentially, under the assumption you got everything right from the beginning in the requirements, your testing will just be an error-finding-and–fixing exercise. However, if you work iteratively, your main goal will be to deliver added value to the customer via the lessons and insights gained through feedback.


3: Defer Commitment

According to the Lean principle of “Defer commitment,” you make decisions that affect commitments as late as possible, which is why the approach is also called “Just In Time Commitment”. By delaying the “freezing” of requirements until you have tested and evaluated different options, you can make better decisions, decisions that are based on the facts and experience you gather, rather than on your imagination. Lean Thinking represents a paradigm shift in requirements work:

You might have been taught that the later you implement a change, the greater the impact and expense. However, without feedback, your requirements work will be based not on facts but on speculation, which (unsurprisingly) often turns out to be wrong in the long run. In other words, early (wrong) decisions based on speculation are much more expensive than the late (good) decisions based on feedback. This is why it’s better to postpone certain decisions, even if it may involve some cost to introduce a change later. What you gain in increased customer value when you make the right, fact-based decision about requirements usually outweighs the cost of making that change later in the process.

In 1987, Barry Boehm stated that it costs 100 times more to make a change in production than to make the same change during the early requirements and design stage. Boehm himself noted in 2001 that his conclusion depended in part on of the fact that we usually work sequentially, based on locking in early-stage decisions. Boehm now believes that working according to Lean principles reduces the cost of changes in production to as little as five times the cost of the same change in requirements and design.

How do I get to this stage? There are a number of approaches.

Prototypes help you quickly produce tangible and visual solutions that work well as a basis for dialogue with clients and fellow team members. If you use prototypes along with proper guidance, the ensuing dialogue will provide you with valuable feedback, which in turn will help you discover the best solution. Usage tests, also known as “usability tests”, are intended to give you end-users’ validation as early as possible, and almost always provide early, low-cost feedback the same way prototypes do (and combining usage testing with prototypes will give you even better input).

So test early and often!