What is Lean Software Development (LSD)

Zia

2 Followers

Follow

May 31, 2024

-

0 sec read

364

0

0

0

LSD is a movement dedicated to reducing errors and wasted time and maximizing education and efficiency. It was originally derived from the IT and manufacturing industries and is now used largely in the programming industry.

LSD is the application of Lean Thinking to the software development process. Organizations that are truly lean respond in a highly disciplined and rapid manner to market demand. This gives them a strong advantage over their competition, which focuses more on predicting the future of market demand. Likewise, Lean Software Development is a drive to create software that can promptly adapt to changes in its domain. It exercises high discipline along with high responsiveness to change. This was derived after observation of extreme types of systems - from unplanned software development to heavy process discipline. Neither was able to sustain, as one system could not scale to large complex systems while the other proved unresponsive to change.

Principles of LSD

Seven key principles form the backbone of Lean Software Development. They are as follows:

• Waste elimination
• Encouraging learning
• Late decision-making
• Fast delivery
• Team empowerment
• Built-in integrity
• Vision of the big picture
  
  
  

1. Waste Elimination:

Anything that fails to bring any additional value to the customer can be defined as waste. The content of waste covers a large area - from time to unnecessary codes as well as functions and requirements that do not make sense.

In the world of software development, waste can be defined as any effort that is non-value-added and could potentially impair the final product. A typical example of this is following the traditional approach of formulating a plan at the beginning of a project, listing detailed requirements. This proves to be a potential waste of time and effort as all the variables cannot be identified in the early stages. If a development team continues with this approach, many unnecessary features will likely be created. In addition to that the team may commit to an incorrect software architecture.

Under 'manufacturing', seven types of waste have been identified:

• Defects
• Overproduction
• Transportation
• Waiting
• Inventory
• Motion
• Processing (extra steps).
  
  

The seven types of waste listed under software development are as follows:

• Defects
• Unnecessary features
• Handing over work
• Waiting
• Incomplete work
• Information gathering
• Processing (extra steps).
  
  

Several tools have been designed to eliminate waste. Some of them are as follows:

1. Eliminate waste by seeing waste:

An example is as follows:

Inventory (partially done work in software development): Inventory has the risk of becoming obsolete on many counts. Whether it is useful or not is determined only after the software system is actually in production. Also, its role in solving business problems is debatable, especially if the system is considered redundant.

2. Eliminate waste through Value Stream Mapping:

Value Stream Mapping is an intelligent way of detecting waste in the software development process that focuses on value-to-client products, rather than organizations, assets, technologies, procedures, and career graphs.

2. Encouraging Learning

Provide all the tools required to have all the resources working on a project, from comprehensive code reviews to documentation. Create a Wiki database along with sufficient commenting, deliver training sessions, and hold group meetings. Understanding their tasks will help the resources deliver better and faster results. A method called pair positioning can be implemented where two programmers team up at the same station and work on separate tasks. In this manner, the less experienced programmer can tap into the knowledge of the experienced programmer, increasing the rate of progress in the project.

1. Encouraging Learning with Feedback:

When a problem arises, the first task is to ensure that the feedback loops are in position. Once they are in place, raise the regularity of the feedback loops in the problem areas. Encouraging and increasing feedback is the most effective way to deal with problematic software development projects and environments.

2. Encouraging Learning with Iterations:

The universal starting point for all agile software development approaches is iteration. Short feedback loops enhance control. Iterations are points of synchronization, where the team and the users see what has been accomplished.

3. Encouraging Learning with Synchronization:

Synchronization is essential when several individuals are working on a single project. It is a fundamental need for any complex development process. Synchronization has to be done at regular time intervals, depending on the need and team size. For example, each team should integrate or synchronize daily, by checking into a local repository, and multiple teams must synchronize every week and check into the central repository. The more frequent the builds, the more feedback they provide. It would be smarter to automate builds and build tests.

4. Encouraging Learning with Set-Based Development:

In set-based development, communication is not about choices, but about limitations. This is regarded as a powerful form of communication, requiring significantly less data to convey far more information. This also delays making choices until they are necessary.

By developing multiple options and sharing constraints, solutions can be sought. When faced with a difficult problem, follow these steps:

• Develop a set of alternative solutions to the problem.
• Test alternate solutions.
• Merge the best features of the solutions or choose one of the alternatives.

3. Late Decision-Making

This process refers to postponing decision-making for as long as possible, especially decisions that will be difficult or impossible to take back. This gives the programming team opportunities to keep their options for gathering information and brainstorming longer. Delaying the process ensures that the correct choice is made when it comes to the deployment of a product. It helps maintain flexibility within the code until decisions are finalized.

1. Decide as Lately as Possible with Options Thinking:

Giving users options allows them to make fact-based decisions based on learning rather than speculation. The commitment to design at a very early stage compromises learning, and aggravates the impact of defects. It also limits the usefulness of the product and increases the cost of change. Drafting elaborate or detailed plans at the beginning of a project could turn out to be redundant. While planning is essential, making decisions about too many variables is best avoided. However, caution must be used when employing this approach.

2. Decide as Late as Possible at the Last Responsible Moment:

Synchronized development helps delay commitment until the last responsible moment, where the possibility of failing to make a decision eliminates an important alternative. Sharing partially completed work increases the length of the feedback loop, causing irreversible decisions to be made sooner than necessary. By going through short, repetitive, exploratory cycles, better work and minimal waste can be achieved. Changes can be accommodated by the use of components with interfaces, and abstractions, avoid repetition, separate concerns, encapsulate variation, and avoid extra features. Ascertain the critical aspects of the domain and also sense when decisions have to be made.

3. Decide as Lately as Possible in Making Decisions:

Intuitive decision-making is preferred as opposed to rational decision-making, as a more mature approach results in good decisions. The following points explore the reasons:

• Rational decision-making involves breaking a problem down, removing the context, applying analytical techniques, and exposing the process and its results for discussion. Do note that there is an inherent danger in intentionally ignoring the instincts of experienced people. It is doubtful that rational analysis will be able to detect high-stakes mistakes.
  
  
• It is more vital to develop people with the expertise to make wise decisions than it is to develop decision-making processes that purportedly think for people.
  
  

An example will help explain this concept better. Marines are expected to plan, but not make predictions. They rely on their understanding of the situation and the assessment of the strengths and weaknesses of both sides. Based on their understanding, they consider boundary conditions and alternative approaches. They encourage varied inputs and settle on a plan with a 110% chance of success. In this manner, Marines manage the project by intent and result. They convey the tasks to be accomplished and the reasons why, leaving the remaining details to them. They learn to strike a balance between discipline and creativity, empowerment and hierarchy, planning and improvisation, rapid action, and careful analysis.

4. Fast delivery

Though speedy delivery is one of the top priorities for programmers, it is not always possible. Fast delivery also translates to less time for changes suggested by users and managers. A conducive environment, where teams can communicate effectively, is key to producing faster and more efficient results.

1. Deliver as Fast as Possible with Pull Systems:

Clarity must be given to each person about how and what they should contribute to the business. The Command and Control method, where resources are told what to do, and the Self-Organization method, where a setting is created so that the resources can figure it out for themselves, are two ways of dealing with it. However, the Self-Organization method works best in the current environment. For effective self-organization, methods for local signaling and commitment must be developed to coordinate work. The slightest variability can render fine-grained assignments in a complex environment. Visual control or Management by Sight is a mechanism where everyone can view the process, the problems, and the progress of the project.

2. Deliver as Fast as Possible with the Queuing Theory:

The fundamental measurement of a queue is cycle time. This is based on the premise that when in a queue, one wants the shortest possible time-cycle. The cycle time can be classified as the following:

• Steady rate of arrival: When arrival of demand is spread out to match the capacity of the system, queues, and therefore cycle times, will be shortened. One way to control the rate of work arrival is to release small packages of work.
  
  
• A steady rate of service: The easiest way to remove variability in processing time is to increase the number of servers that process work in a single queue. Small work packages will allow parallel processing of small jobs by multiple teams. Therefore, in case one is stalled by a problem, the rest of the project can proceed without delay.
  
  
• Slack: Short cycle times are not possible if resources are overloaded. Full utilization provides no value to the overall value stream but is often detrimental.
  
  

3. Deliver as Fast as Possible - Cost of Delay:

Several benefits can be gained through rapid development. The following exercise shows how they can be used:

• Create a simple economic model of a new product for the next few years; for example, a Profit and Loss account.
• From the marketing team, get a rough estimate of the effect of delays on sales volumes and market share.
• The result of the given step will illustrate the effect delays can have on profits.
• The cost of delay can be very high if delay stands for loss of early high pricing or long-term loss of market share.
• Keep the model relevant and simple to get buy-in from everyone, by taking help from the Accounts team.
• Economic models could help you justify the cost of reducing cycle time, eliminating bottlenecks, and purchasing tools that will allow faster deliveries. They can also help drive development decisions.
• By presenting the economic model, the team is empowered to think beyond their deliverables and ascertain what is important for the business. Since the frame of reference is the same, decisions and suggestions can be derived from the same platform, reducing the probability of variables.
  
  
  

5. Team Empowerment

Lean team management requires managers to ensure programmers are not overloaded. They should also be able to establish a reasonable workflow. Motivation for the team is key to producing the best results. One way of motivating the team is by involving them in the decision-making process.

1. Empower Your Team with Self-Determination:

Self-determination works well as a concept, however, practical application and the ability to sustain growth over time, is especially difficult.

2. Empower the Team with motivation:

Motivation is vital to performance. Some vision statements from William McKnight, a leader of 3M from the 1930s through the 1950s are as follows:

• "Hire good people and leave them alone."
• "If you put fences around people, you get sheep. Give people the room they need."
• "Encourage, don't nitpick. Let people run with an idea."
• "Give it a try - and quick!"

Self-motivation calls for a feeling of belonging, safety, and competence along with a sense of progress.

3. Empower Your Team with Leadership:

1. Respected Leaders: Usually behind a great team is the hand of a great leader. The leader works with the team on initial concepts, sets the pace of progress, and determines how decisions are made.

Coping with change:

• Set the direction.
• Align People
• Enable motivation
  
  

Coping with complexity:

• Plan and budget.
• Organize and staff.
• Track and control
  
  
  

2. Master developers: Includes chief programmers, architects, and system engineers. Some reasons why master developers make good leaders are as follows:

• In large systems, a small team of exceptional designers comes forward to take up primary responsibility for the design. Exceptional designers are singled out for leadership based on their superior knowledge.
  
  
• They are familiar with the application domain and the technology, and therefore, serve as experts in providing technical guidance.
  
  
• Their understanding of both users as well as developers puts them in a unique position. They recognize the system's constraints, interactions, unstated requirements, exception conditions, and likely direction of change.
  
  
• They have a bird's eye view of the process, but their in-depth knowledge helps in identifying problems at the micro-level. This helps developers and engineers, as they can benefit from their expertise.
  
  
• They form the heart of the team, as they are responsible for communication and leadership. Additionally, they assist the team in making good decisions, making rapid progress, and developing high-quality software.
  
  
  

4. Empower the Team with Expertise:

Though a great deal of information can be stored in books and other mediums, they cannot replace oral knowledge-sharing, a medium for tacit knowledge. Some of the details that are shared in this mode are as follows:

• Standards are developed by a group of experts, as and when it is required by the program team.
• It is recommended that program teams work with existing standards rather than develop new standards.
• Fostering communities of expertise, where standards are lacking or haphazard, helps overcome sloppy work, as (new) standards are developed.
• Developers appreciate reasonable standards, especially if they have helped in developing them and in keeping them relevant.
  
  
  

6. Built-in Integrity

One main aim of the team should be to produce high-quality code. As discussed earlier, there are several ways to do so - pair programming, continual testing, creating small modules of code, and automation.

1. Build Integrity - Perceived Integrity:

Cleaved integrity is when a system appears to know what the user wants from it next. When put in the context of a software development process, the following points are important to note:

• Companies that want to achieve perceived integrity should aim to put the vision of the users before themselves as well as the technical team. Chief engineers have added to their engineering and leadership skills the ability to understand the target customer base and create a vision.
  
  
• Although customers know what they want from a design, they can't determine everything that should be a part of the design. This can prove to be a problem when situations and user's perceptions change.
  
  
• Domain models must be both understood and directly usable by the user and by the developers writing the code. Through joint modeling, the understanding of both the team as well as the users will be the same. This is applicable when it comes to domain issues as well as implementation. This method is known as Model-Driven Design.
  
  
• Software that reflects the domain model is more adaptable to market changes than software with significantly different internal structures chosen for technical reasons.
  
  
• There is usually a gap between the design on paper and in actuality. The best way to bridge this gap is to deliver tests along with the code, a high-level overview model that was created at the beginning of the development phase.
  
  
  

2. Build Integrity - Conceptual Integrity:

Conceptual integrity is the principle that you can tell that a design is part of the same overall design. Irrespective of where you look at it from. Some of the salient features of this tool are as follows:

• When the components work well together, the system architecture will be able to balance flexibility, maintainability, efficiency, and responsiveness.
• Conceptual product integrity can be achieved by maximizing the effectiveness of communication mechanisms. These mechanisms are developed among engineering groups.
• The use of existing parts removes many degrees of freedom and reduces the complexity and requirement for communication.
• The use of integrated problem-solving is recommended to ensure a smooth flow of technical information. This can be executed in the following ways:
  
  a. Understanding and solving the problem at the same time, not sequentially.
  b. Release of information as and when possible, instead of holding details until all the information is available.
  c. Transmission of information in small batches, at regular time intervals, rather than sending a large transmission.
  d. Two-way information flow.
  e. Encourage face-to-face interactions as opposed to communicating documents.
  
  
• Forecasting can lead to a significant loss of time and effort in an uncertain/changing environment. It is advisable to take the breadth-first approach and get the basics right. Once this is fixed, encourage discussion and brainstorming to generate ideas. Post this phase, plan for regular refactoring to keep the architecture healthy.
  
  
  

3. Build Integrity ln - with Refactoring:

Refactoring is based on the premise that complex problems require simple solutions; however, finding simple solutions takes more than one attempt. Engineers start with something that works, learn from its weaknesses, and improve the design.

Conceptual Integrity can be maintained by refactoring when a system begins to lose the following characteristics:

• Simplicity
• Clarity
• User-friendliness
• No repetition

Good design evolves over the life of a system. Poor code does not get better by being ignored. In such cases, it is important to:

• Stop the line of action or code development when something does not seem right.
• First, take the time to dig for the root cause of the problem and fix it from the base, then proceed to the next development.
• Too much time shouldn't be spent on non-value-added activities.
• Refactoring is not cost-intensive but pays like advertising.
  
  
  

4. Build Integrity - with Testing:

Programming has increased in scale, from a point where programming was done one module at a time, to programming entire capabilities and features. This has blurred the lines between units. System, and integration tests. One of these tests would be developer tests - tests that ensure the code does what the developer intended it to do. Acceptance tests involve tests that ensure systems do what customers expect of them. These tests are usually scheduled at the end of the development stage. These can also be called customer tests.

In a situation where the time provided is not sufficient, reallocate resources from requirements documentation to writing consumer tests. Tests should be automated as much as possible and run as part of the daily build. The tests conducted should be accurate and comprehensive. They should be put under version control and automated and under continuous process improvement. By maintaining and running all-inclusive tests throughout the life cycle of the system, you can guarantee that the system can be safely repaired and refactored throughout its life span.

If the tests are clear and well-organized, they serve as a resource. They provide a clear understanding of how the system works, from the user's point of view as well as the developer's point of view.

7. Vision of the Big Picture

The Lean development teams ought to view the project as a whole, not as separate segments. The entire project should be kept in mind while setting goals and mini-goals. If not, codes will be written haphazardly which gives way to bugs.

1. See the Whole with Measurements:

Optimization of every single task can prove harmful to the project. It is difficult to measure work that is qualitative as there is no standard for it, especially when it is unique and ambiguous. In such cases, it is best not to sub-optimize - a practice where parts of an important qualitative piece of work are optimized as it cannot be measured accurately as a whole. The best way to ensure the measurement of all tasks is aggregation, where the measurement is moved one level up, not down.

Information measurements, which are an aggregate of the performance of a team, should be used instead of individual performance data. It is not ideal to track defects per developer, as less than 20% of all defects are under the developer's control. The remaining percentage of defects is caused by existing systems and procedures, which fall under management's purview. It is important to get to the root of the defect, which can be achieved by encouraging the collaboration of the entire organization in rooting out defects.

2. See the Whole Contract:

Project managers control four variables - time, costs, quality, and scope. Of the four components, time, costs, and quality can be fixed. While drafting the initial plan, prioritize features and keep the scope negotiable. In this manner, you can deliver high-priority features first. You can present to the user most of the business value long before their wish list is completed. As per a study by the Standish Group, up to 45% of the delivered features are not used. Barry Boehm and Philio Papaccio noted that the best way to develop low-cost, high-quality software is to write less code. Rigid control of the scope tends to expand it. Overall cost savings can be achieved by working with the customer using a form of optional scope contract.

These seven principles guide the software development process to achieve maximum efficiency while offering maximum value to the user. Merging smart workflow design and the right attitude produces high-quality results, taking into account the important parameters.