Lean, a philosophy, a framework that has laid the foundations for better, more effective processes, practices, and techniques in a large variety of situations for individuals and businesses. It defined a set of principles and practices to guide you in extracting the most value from your efforts but does not lay down exact steps that tell you how to implement those practices.
The Philosophy derives its origins from Toyota Production System, which sought to eliminate seven wastes or unnecessary steps from the production processes in Toyota. As a result, the term lean came into existence in the 1990s. With the growth achieved by Toyota, lean gained increasing interest and acceptance as a practical management philosophy.
Mary and Tom Poppendieck first coined the lean software development term in a book with the same name. They adopted and translated lean manufacturing principles to apply to the software development process. They did this by identifying seven lean principles and 22 tools for practical agile projects.
Table of Contents
Seven Lean Principles
The seven lean principles that help you ensure that the team adopts a practical agile mindset are;
- Eliminate waste
- Amplify Learning
- Decide As Late As Possible
- Deliver As Fast As Possible
- Empower The Team
- Build Integrity In
- See The Whole
These seven lean principles have tools and techniques that allow you to practically implement these principles. There are 22 such tools. Let’s now see each of these lean principles and tools in detail.
First principle: Eliminate waste
Taiichi Ohno considered the father of the Toyota production system, first applied lean principles to the manufacturing process of cars. The company’s challenge was to produce cars as cheaply as otherwise possible without taking the risk of having more quantities than market demand. Ohno looked at removing every step and component from the manufacturing and supply processes to overcome the challenge, which did not directly contribute to the ultimate customer deliverable. If an element was not required or an operation was not directly responsible for the final delivery, it was cut down. Because of this, it became possible to focus the efforts on things that produced direct and tangible value.
Eliminating such waste is the most important principle of Lean theory. Moreover, it is the basis on which the rest of the principles are built.
Eliminating waste is an iterative process, where the team first identifies the most significant source of waste on projects and eliminates them. Then they identify remaining sources of waste and get rid of them. When even those activities that seem to be essential first, there comes a time, might be recognized as the waste finally, and the process contains only a critical, necessary set of activities.
For these activities, the Lean programming theory provides us with two tools. And these two tools are Seeing Waste and Value Stream Mapping. So let us now see each of these tools in detail.
Seeing Waste
Waste is any project activity that does not directly add value from the customer’s perspective. Unnecessary & complex documentation, complicated and lengthy approval processes are a few of the examples. Shigeo Shingo, an expert with Toyota Production System, identified seven wastes in the manufacturing process. Since these seven wastes cannot be directly applied to projects involving software development or service delivery, Mary and Tom Poppendieck mapped them to seven wastes encountered on such projects. These seven wastes are;
Partially Done work
A feature, which has been started but left undone, represents a waste. No one can be sure about whether such an incomplete feature would be of value to the customer when completed. Also, there is quite a chance that actual requirements governing the development of that feature might change when it is complete and may become a wasteful exercise. Project teams implementing Lean principles should look out for such partially done work and seek to influence circumstances that result in partial work. You might do it by keeping the development small and delivering in short increments in quick iterations.
Extra Processes
You must examine document approvals, change management, work authorization systems, every process on the project to see if they are essential from the value delivery perspective. However, even when they are crucial, lean teams should strive to keep them simple and efficient.
Extra Features
Features that do not contribute to the value for customers should be avoided at all costs. Such elements take up effort and time. And apart from being not necessarily required, they eat up time that could have been spent on more crucial features, thus delaying value delivery to customers.
Task Switching
Multitasking has become a common phenomenon in practical life. However, there is a growing recognition that working simultaneously on multiple tasks is a drain on productivity and risk for quality. Significant time is wasted when an individual working on one task switches to another until that individual can be productive on the new task. Furthermore, frequent switching between tasks tends to increase the wasted time. Lean looks at multitasking as waste and suggests avoiding it.
There is also a problem of late value delivery. For example, suppose a person is supposed to take one day each for two tasks for which she is responsible. If she chooses to do half of each task for two days, she will complete both tasks after two days. However, if she finishes one task on the first day and another on the second, she would have delivered value on the first task faster, without delaying the value delivery on the second task.
Waiting
Delays happen in project activities due to various reasons. For example, it might be cumbersome processes, size of documentations, delay in approvals or sign-offs, delay in getting project team members on board, so on and so forth. And these delays result in increasing the time for which the project team members wait to start a dependent activity. Higher waiting time results in late value delivery for the customer. In addition, it decreases the time the team takes to respond to changes, thus defeating the very purpose of implementing agile life cycles.
However, it is curious to know that one of the lean principles is to delay the decision as late as possible. We will talk about this principle in detail later on. Still, for treating waiting time as waste, it is essential to note here that delaying decisions are only permitted to the extent that it does not negatively alter the outcome.
Motion
The sixth waste, motion, is linked to waiting and refers to the time required to take action. For example, a developer might need clarity on requirements. How soon does she get it? How soon is a developer able to know the results of a test? So that they can make any corrections? How soon can the team respond to issues? The faster this happens, the quicker is the value delivery. For this very reason, colocation is a recommended practice for agile implementations.
Defects
Defects result in rework. Rework means duplicate efforts. And the longer it takes to uncover a defect, rework efforts might be higher. Thus, reducing the impact of defects is a critical agile objective. This objective is why practices like continuous integration, test-driven approaches, and shorter iterations are agile recommendations.
Learning to see waste is an ongoing activity. The focus should be on identifying what is unnecessary from the customer’s perspective and getting rid of that. The Value Stream Mapping is a tool that provides an effective way to accomplish this.
Value Stream Mapping
A value stream depicts the flow of activities and process steps required to deliver customer requirements. It usually starts when the customer request comes in and then traces the movement of that request through the entire life cycle until the delivery against the need. The actual time spent on value-adding activities and time wasted in waiting and non-value-adding activities is also noted along with the process steps. Based on this map, you can evaluate the process to determine bottlenecks. In addition, you can identify areas where opportunities exist to increase the value-added time by cutting down on waste. The updated value stream map can again point you to the next possible waste reduction step.
Second Principle: Amplify Learning
Software Development or Service Delivery project processes differ from manufacturing processes. With manufacturing processes, you seek to produce identical outcomes repeatedly. Software development projects, on the other hand, look to deliver solutions to unique problems. The requirements might have an element of repetition, but there will be specific different components each time. The essence of uniqueness makes software development projects exploratory in nature. The experimental approach mandates a cycle of trying, testing and fixing each unique component.
To make this exploratory approach work, the team must learn what is working, what is not working, and what needs to be fixed. The faster and efficient this learning mechanism is, the more efficient will be, the value delivery. Lean principles provide for four tools to this effect.
Feedback
Traditional project management and software development processes take a deterministic approach towards projects. These approaches are based on the assumption that all details of the project can be determined initially. These approaches seek to finalize requirements and execution details initially and attempt to follow that plan by minimizing changes or deviations during project execution and development. As a result, there is a lack of feedback mechanism to enable the team to learn about unforeseeable events and respond to those changed circumstances.
Lean, on the other hand, advocates an approach with more frequent feedback loops. Such short feedback loops allow for quick adjustments to what is being done and what requires to be done. The frequency of feedback loops is increased by various means;
- Testing the code immediately, without letting the defects accumulate
- Uncover exact requirements by actually writing code and through prototyping
- Select the appropriate tool by shortlisting the best few rather than trying an assortment of tools
- Instead of trying to do too much at one go, develop incrementally and iteratively, testing one idea at a time.
- Accept and respond to customer feedback immediately.
Iterations
Similar to the Just-In-Time approach used with manufacturing, lean for software development uses the concept of iterations. Iterations provide a short, fixed timeframe to deliver a working product against a smaller, immediate set of requirements and priorities. This approach offers a greater understanding between developers and customers, helps uncover quality issues quicker, exposes design problems early, and builds change tolerance into the process.
The three fundamentals on which the iterations-based approach is developed are Queuing theory, options-based technique, and synchronization of diverse viewpoints. With queuing theory, small batches move through the system. These small batches allow for shorter feedback loops, ultimately enhancing the control over development. An approach based on Queuing theory also enforces quality and better collaboration resulting inefficient utilization of resources. The options-based system allows the team to respond to facts rather than forecasts. By keeping options open, the team can better respond to the unanticipated situation. This flexibility works as a better risk management strategy rather than fixing everything upfront. Finally, with iterations based approach, the team delivers a potentially shippable product with every iteration. This incremental approach allows for more excellent synchronization between people, teams, and customers.
Synchronization
The fifth lean tool is synchronization. Agile approaches advocate co-ownership of the code. No single team member owns the code; it is collective team ownership. Anyone is allowed to change any part of the code. It becomes essential in this scenario to ensure that such code changes do not break the entire system. Synchronization provides the way for continuous integration and ensures that the code is always in working conditions.
The lean approach towards synchronization puts forth the idea of daily builds and smoke tests. In the morning, the developer will check out the code from the configuration management system and work on that code during the day. Next, the developer will ensure that the checked-out code works correctly, checks if someone else has modified any part of the system code, resolve conflicts between different changes, and checks-in the code back into the configuration management system. Then, through an automated process, all the modified code is incorporated into a build. Finally, a set of automated tests run against that build to ensure that the system as a whole works correctly.
Set-Based Development
There may exist multiple solutions to one development problem. Instead of finding which option is the best through discussions about the feasibility of each solution, lean provides a set-based development approach to develop multiple solutions, discuss the constraints of each solution, and let the solution emerge by considering the limitations. Set-based development adds a new dimension to iterative development. Early iterations are used to develop multiple options, and later iterations are used to merge different solutions towards one solution by finding the best from all options.
Third Principle: Decide As Late as Possible
Traditional software development and project management approach attempt to fix design and execution decisions early in the project. At this stage, all the details are not clear. Decisions are taken based on the assumptions about details expected to emerge in the future. Project efforts are committed based on these assumptions. Such a depth-first approach makes it difficult to change the course if any assumptions prove to be invalid during the project.
On the other hand, Lean takes a breadth-first approach, which means working on high-level highest priority requirements first as soon as a conceptual design is ready, even while the lower-level details of the requirements are unclear. This approach is made possible by developing multiple options but not committing to any single option too fast. This strategy helps mitigate the risk of cost escalations as changing course is not difficult since the efforts are not engaged in any one direction.
The principle of Deciding as late as possible is implemented using three tools; Options Thinking, the Last Responsible Moment, and Making Decisions.
Options Thinking
Options Thinking helps make decisions based on real-time information and feedback rather than on speculations. Such decision-making is made possible by developing multiple high-level options during initial iterations. Based on customer feedback and constraints-based thinking, later iterations then pick the best possible solution out of all available options. Options thinking allows flexibility until the uncertainty is removed from the project by differing final commitments but still provides the team with an ability to deliver once the decision is made based on options quickly.
Last Responsible Moment
However, you can’t delay decisions infinitely. There comes a time when if the team does not make a decision, it is made by default. This situation takes away the control from the team and is not a very desirable situation. The last responsible moment represents when a vital alternative might become unavailable if the decision is not made. Please note that delaying decisions till the last responsible moment is not equivalent to procrastination. Instead, it is a deliberate attempt towards making commitments only when sufficient insights are available.
To ensure that the last responsible moment is not lost, some tactics can benefit a project team.
It is okay to share partially complete design information. Waiting till the full design emerges increases the feedback loop. Such a long wait might pose a risk of irrevocable decisions being made without allowing all the details to emerge. Suppose the design is treated as a discovery process, done through short and repeated exploratory cycles. In that case, it allows for committing to a decision without the risk of undoing much work.
The second tactic is to allow for direct collaboration between team members. Such partnership allows the customers to pass on the knowledge about what the system must do to provide value to the developers who know the details about converting those requirements into code.
Developing a mindset receptive towards change is the third tactic. You can do this by practicing object-oriented or component-based development practices.
The teams must know what is critically important for the domain. This tactic ensures that nothing is left out of consideration when finalizing the design or making final decisions. With traditional approaches, few very critical aspects of the successful delivery may not get considered, as early commitments narrow down the view of the project teams.
The fifth tactic is to develop a sense of when the decision needs to be made. You must develop a keen sense of timing to identify the last responsible moment, and decisions are not made by default.
The last tactic is to develop the capacity to respond quickly once the decisions are made. The ability to respond faster makes delaying the decisions possible.
Making Decisions
Options thinking and Last Responsible Moment enables the breadth-first style of decision making, advocated by Agile principles, to be effective. The breadth-first decision-making style delays commitments. It is more of intuitive decision-making rather than rational decision-making. Hence, it takes a domain expert and savvy individual to understand how the details will emerge in the future and when it is time to decide by identifying the last responsible moment. However, the intuitions are based on real-time information and feedback generated through various options.
We are at the end of the third principle of the Lean approach. The fourth principle is Delivery as Fast as Possible.
Fourth Principle: Deliver As Fast As Possible
This principle compliments the principle of deciding as late as possible. The faster you can deliver, the longer you can wait to make commitments. If you can do something in one day, you have to decide how to do it only one day in advance. However, if you will take a week, you need to select one week in advance. The longer delivery time increases the work-in-process items, thereby increasing the risk of rendering the efforts useless if circumstances or requirements change, decreases customer satisfaction as they have to wait longer, and the possibility of defects in the work increases. Rapid delivery mitigates these risks.
Three tools help you deliver rapidly. They are; Pull Systems, Queuing Theory, and Cost of Delay. Let us see them one by one.
Pull System
If the developers have to wait for directions from the above to decide what work they need to do, it might increase the waiting & response time. Lean and Agile approaches self-directing teams, who decide how to respond to any work. If things happen rapidly, there is not enough time to wait for the information to travel down through the chain of command. The pull system, where the developers can decide the work to be done next from the remaining work, provides teams with a tool to enable this process. When the directions for the work are given through complex and linear scheduling mechanisms, they do not respond to changes very effectively. A pull system offers this flexibility, as it employs a Just-In-Time approach to the work to be done. A primary example of pull systems is Kanban.
Queuing Theory
The fundamental idea behind queuing theory is to reduce the cycle time. The cycle time is the time for an end-to-end process, from start to finish to complete—the shorter the cycle time, the better will results. The reduction of the cycle time is achieved through two mechanisms.
Steady Rate of Arrival
The cycle time for the work grows proportionately to the size of the work package. Longer cycle time indicates an inefficient process. Also, variations in the frequency of work arrival make it challenging to efficiently spread the work across available time and resources. The queuing theory tries to break down the work into smaller and consistent chunks. By breaking down the work into smaller pieces, the rate at which the new work is introduced can be controlled and made uniform. In addition, the prioritization helps distribute the work by undertaking activities with more value first and working on lower priority activities later on. Finally, by controlling the arrival rate, the cycle time is reduced as the smaller pieces move faster through the end-to-end process.
Steady Rate of Service
The second mechanism is to remove the variability from the process. With the steady rate of work arrival and smaller work packages, you can distribute the load across multiple teams and people for parallel processing. Such distribution ensures that even if one package faces issues and takes longer, the queue still moves at a predictable rate as other people or teams will still complete the work rapidly. Thus, the queuing approach allows for a consistent pace of delivery and reduces overall cycle time.
Slack
When the work fills all the available time, it leaves little room for accommodating the change. Working at 100% capacity is not very sustainable, as the lack of bandwidth creates the bottleneck. Larger batches take up more time and require a higher number of people. Moreover, they do not provide any flexibility if any course correction is needed. Leaving some slack into the system enables people to ensure quality and have flexibility, thus reducing overall cycle time.
Cost of Delay
Early delivery brings in many benefits. Besides giving an advantage over competitors, it also allows starting to reaping benefits from the product early. Since the product also stabilizes early, the support and maintenance costs also start reducing early. If the delivery is delayed, there are direct and indirect additional costs attached with it. Sometimes, such costs of delays are not considered when making project decisions.
It is essential to understand the relationship between time and cost to understand the cost of delay. An economic model, which represents the profit and loss statement for the product over a pre-defined timeframe in the future, can provide managers and business decision-makers with the idea of costs related to the delay. This Profit and Loss statement provides a quantified view of the costs of delay.
One thing to note here is that deliver as fast as possible does not mean that teams rush through to complete the deliverables. But it means that you can only delay the delivery till profits are not impacted. Waiting beyond that point starts having a negative impact.
Fifth Principle: Empower the team
The traditional view of process maturity attempts to divide the whole system into disaggregated parts and then optimize those individual parts. The focus is on planning everything and then implementing a top-down control mechanism to ensure no deviations from the plan. This approach restricts people from looking at problems or work at hand creatively and decreases motivation. The lean theory works on two assumptions, distinct from the traditional process maturity approaches. The first assumption is that a mature organization looks at the whole system as one and does not optimize disaggregated parts. Second, it focuses on learning effectively and then empowers the front-end teams, the teams who do the actual work, to make decisions. Such organizations expect teams to design their work with training, coaching, and assistance. It is also likely that the teams will continuously improve their work due to the continuous learning process. In addition, such an organization will ensure the availability of time and equipment necessary to perform well on their job. In a lean organization, the front-line workers will have process design authority and decision-making responsibilities.
Self Determination
A team must come up with its processes and practices. Generally, improvement programs look at replicating the tools and techniques that worked successfully in one instance. But copying only those tools and techniques does not suffice. The fundamental principles must be understood and replicated. If those fundamentals are replicated correctly, you can use any tool. This concept is the essence of Self-Determination. True success can’t be replicated by managers telling the worker what needs to be done and how. Instead, managers’ role is to coach, train, and assist the teams. But the teams must decide how they want to approach the job. There must be a feedback loop going on between managers and the team to facilitate this process. The continuous learning process and feedback loop also help teams and managers both to improve.
Motivation
The sense of shared purpose motivates people more than anything else. When the team is working towards one goal, it tends to inspire the team. The purpose is what makes work energizing and engaging. It must be clearly stated and should present an achievable but compelling vision to motivate people. To ensure that the team becomes motivated and capable of achieving the purpose, they should have access to customers and make their commitments. The freedom of making commitments provides a sense of ownership, which increases the feeling of shared purpose. In such scenarios, the role of management is to help the team remove hurdles by listening to the team’s feedback and provide guidance at a very high level. Such an environment generates a feeling of belonging, which is one of the building blocks for motivation.
Sense of safety, Competence, and progress sustains the motivation. When the decision-making is delegated down the line, the team might make a few mistakes. However, continuous learning, coaching, and guidance ensure that such mistakes are fewer and are not driven often. An environment that tolerates such errors and helps the team recover from them helps maintain the motivation in the longer run, increasing the benefits of empowered teams.
When teams achieve something on their own, it will increase their sense of competence. People must believe they are capable of doing a good job. The feeling of competence comes from knowledge and skills, positive feedback, high standards, and meeting a difficult challenge. With necessary guidance from the manager, you can empower such teams to be successful.
It is challenging to sustain motivation for a longer term if the team does not feel that they have achieved something. The iterative development model goes a long way in providing this sense of progress as a working product is produced in short and frequent iterations.
Leadership
The shift from managing people to that of leading people goes a long way towards building empowered teams. A managerial approach entails dealing with complexity with a top-down approach. At the same time, a leader would trust and guide the team towards handling the complexity by building an adaptive change mindset. A manager would plan and budget, organize and staff to achieve the planning goals and then track the progress and control the work to ensure compliance to the plan. On the other hand, a leader would set high-level directions, align people towards the shared purpose, and motivate them to achieve the goal.
The empowerment of the teams comes from such leadership through a master developer. The master developer understands the domain, is skilled at communicating a technical vision to development teams and understands both customers and developers. Such a master developer usually emerges as a respected leader because of their extensive expertise. They are generally not appointed. Even when they are appointed, they should demonstrate such expert power. To this effect, lean philosophy encourages project managers to become more of a project leader.Â
Expertise
The effectiveness of an empowered team can be attributed to the expertise. When communities of experts are developed and fostered across the organization, it helps spread the knowledge and promote learning. Traditionally, the expertise within the company is organized into a matrix structure, where departments permanently house specific functional experts, which are pulled into projects as required. However, this approach has issues like split loyalties or one of the functions dominating others. For matrix organizations to work effectively by overcoming such weaknesses, functional managers must view their job as mentors, and teachers and project leaders view their job as enablers and motivators. By promoting a culture of mentorship, the expertise gets passed across all levels and enables the empowerment of teams by making such experts available to them.
The communities of expertise can build the standards required to ensure that the quality of delivery is optimum. In addition, the standards ensure that a high level of knowledge is indeed implemented into practice.
Sixth Principle: Build integrity in
When we talk about products, software, or otherwise, product integrity has two aspects; the first aspect relates to how the product is perceived externally, say by the customers. For example, does the product solve their problems? How usable is the product? How reliable is the product? These characteristics determine the perceived integrity of the product.
The second aspect of product integrity deals with how well the internal parts of the product work as a whole? For example, how maintainable is the product? How flexible and scalable is it? How responsive is the architecture? These aspects define the internal or conceptual integrity of the product.
The conceptual integrity is required for higher perceived integrity, but it alone is not sufficient for making a superior product. If the product does not meet user needs, the best architectures will not alter user perception. It is for this reason that conceptual integrity will emerge as the systems evolve. The architecture will have to evolve along with system maturity. When a high level of perceived and conceptual integrity is achieved, it gives rise to a superior product.
Perceived Integrity
The development team must have continuous access to insights about what exactly will provide value to the customer to achieve perceived integrity. Thus it’s only possible through constant collaboration between customers and the development team. Both these entities must collaborate from the same platform because what the customer is saying must be correctly understood. Still, the developers and customers must be able to understand what the developers are doing correctly. From this perspective, the perceived integrity is based on three supporting pillars; iterative, test-driven development with customer involvement, model-driven development, and change accommodating mindset.
Customers often will not articulate their exact requirements, nor will all requirements be evident initially. Iterative development provides customers with a tangible working subset of products incrementally and frequently, allowing customers to uncover details about their needs and present their exact requirements to the development team by looking at how the working product functions. On the other hand, customer acceptance tests provide developers with an accurate idea about three products they have to build.
The model-driven development provides both customers and developers with a common language, so the expression and understanding by both entities are always on the same platform. In addition, the ubiquitous nature of the model enabled excellent customer developer information flow.
Since the system will continue to mature and evolve, the customer’s sense of value will change. If the product cannot stay relevant in the face of such changes, its perceived integrity will start to diminish. A mindset accepting and welcoming change will ensure continued perceived integrity for the product.
Conceptual Integrity
The perceived integrity can only be achieved and maintained if the underlying product architecture balances flexibility, maintainability, efficiency, and responsiveness. The first step is to try to remove complexity as much as possible to achieve this balance. You may do this by reusing existing components. Such reuse minimizes possible options and makes the design that much more straightforward.
The second step is to use the integrated problem-solving approach. It means that the information flow is not delayed until complete information is available but immediately solves the immediately known problems. This approach enables and requires bi-directional communication, which releases information in small batches. The preferred mode of communication is face-to-face. This approach keeps the feedback loops short, breaks down the complexity into smaller entities, and allows for the feedback to be incorporated into further design and development.
The conceptual integrity will emerge from such iterations. It will help the architecture achieve the scalability and flexibility required for long-term perceived integrity while providing the optimal design.
Refactoring
As the design process goes on, suboptimal design parts are included in the system architecture. The ongoing process to remove the suboptimal parts of the design and replace them with the most optimal components is refactoring. Refactoring allows the architecture to remain healthy as the system matures and evolves. Refactoring helps maintain the conceptual integrity of the product over a while by introducing simplicity in the design. Removing unnecessary complex design parts also helps provide clarity of purpose to various design components and helps developers understand the code better. The clarity of purpose ensures the suitability for use. The refactoring also helps remove duplication from the design, which makes it scalable. Refactoring also helps ensure that the system remains lightweight and accurate to its purpose as it allows for the removal of unnecessary, extra features.
Testing
Testing ensures that both the perceived and conceptual integrity is properly built-in in the development process. Furthermore, since tests communicate how things should work, they provide feedback on whether the system works as intended and designed or not. Testing at every step thus provides scaffolding for making frequent changes necessary for emerging conceptual integrity. Thus, a complete, automated developer and customer tests suit provide more payoffs than most other product development investments.
We are at the end of the sixth principle of lean development theory. Next, let’s head to the seventh and last principle, optimize the whole.
Seventh Principle: See the Whole
A product is a system of interdependent and interacting parts joined to fulfill a specific purpose. From this perspective, how different parts behave and interact with each other is more meaningful than considering how well each independent part functions. Systems thinking is a way to look at overall interactions between all these parts. The computerized analysis of the system by simulating such interactions is called systems dynamics.
Systems thinking and systems dynamics help us understand that a system is not just the sum of its parts but rather a product of interactions between individual components. However, when these interactions are ignored and focus shifts to optimizing individual parts rather than understanding the broader impact of the exchanges, it leads to sub-optimization.
Generally, when the organization starts facing problems with the system, the tendency is to implement more stringent process control, resulting in increased sequential processing. However, such a sequential approach towards process control might improve the situation in shorter terms but cannot solve the core issue. This phenomenon can be explained by three common patterns of systems thinking; limits to growth, shifting the burden, and sub-optimization.
Limits to Growth
Any process, which may produce the desired result, will also have a secondary effect that might eventually slow down the process. As more thrust is put on strengthening that very same process, the secondary effect starts exhibiting more intense impact. Systems thinking suggests that instead of pushing for growth, one should look at the constraints limiting the growth and removing those constraints.
Removing the limits to growth has been the core teaching of the theory of constraints. However, this is an ongoing process, as removing constraints from one place will create another limitation at some other place.
Shifting the burden
The second pattern, shifting the burden, explains how people might be more challenging to address the symptoms themselves instead of resolving core issues. This approach essentially results in a quick-fix approach, which might make the core problem more serious.
Lean thinking promotes the idea of five whys to address the issues exhibited by these patterns. First, for every problem reported, you ask the reason why the problem occurred. Then, you repeat asking the why questions five times, every time getting near the core issue. It is expected that after repeating the why five times, you would reach the underlying problem.
Suboptimization
The third pattern is that of suboptimization. It is quite common to divide large systems into parts and then try to optimize individual parts. But as we have discussed earlier, if the overall impact of the particular process on other processes is ignored, it leads to suboptimization of the entire system.
There are two tools that lean philosophy offers for us to ensure that the team looks at the holistic picture rather than focusing on individual parts of the system. These two tools are; measurements and contracts.
Measurements
The general practice is to decompose the system or projects into parts and trying to optimize those individual parts. Performance measurement systems are designed for departments, teams, and individual persons to determine the need for optimization and assess the progress. Measuring the performance of a knowledge worker is a challenging thing in itself. But that apart, such performance measurement focuses on local optimization. The problem with such local optimization is that people tend to focus only on what is being measured. It ultimately leads to sub-optimization.
Second, most of the time, an issue or a defect cannot be attributed to a single or single entity. Instead, the defect can be generally attributed to many sources, including development systems and procedures. The pattern of shifting the burden is demonstrated when such factors are ignored. Instead, an individual is held responsible for all defects or issues.
To avoid both these issues, sub-optimization and shifting of burden, it is essentials that the entire development organization is encouraged to collaborate on finding the root causes of the defect. Aggregating defects and issues assist in finding the root cause. The aggregation also means that the measurements keep on moving to higher levels rather than to lower levels. This approach will provide a broader outlook towards the system issues, and collaboration will ensure that the root causes are identified and resolved.
The lean philosophy suggests that if we cannot measure everything this way by aggregating measurement at progressively higher levels, measurements do not serve their real purpose. Therefore, they are better not performed in this case.
Contracts
Contracts govern association between entities. They are generally used to specify each associated entity’s roles and responsibilities by putting things in written format. The general tendency is to use contracts to protect the interests of each company. However, in practice, the contracts are used to ensure that parties cannot possibly take advantage of each other. This tendency stems from the notion that each party may exploit the other party’s vulnerabilities to protect its interests. From this perspective, the contract attempts to replace the idea of trust between associated entities that the other party will fulfill its promises and will not exploit its vulnerabilities.
When used as a mechanism to keep parties from taking advantage of each other, contracts have many built-in checks and controls. However, excessive controls and checks tend to increase the overall cost of executing the contract. Apart from the direct costs paid to the suppliers, there are other indirect costs attached to administering such a contract. Also, such contracts tend to change intolerant. The tendency is to define everything in the contract and then protect the execution from any deviations.
Such a type of approach goes against the fundamentals of Agile thinking. Furthermore, the change adopting and collaboration-focused nature of agile project management does not work well with many types of contracts, for example, fixed-price contracts. Fixed price contracts try to transfer the risk to the vendor and stifle changes. While working with an agile project, it is, therefore, necessary that contracts are chosen appropriately.
You can consider three types of contracts for this reason;
The time and material contract Though this type of contract provides little incentive to vendors to be efficient, careful execution can negate such consequences. The customer will require the vendor to provide the most valuable features implemented in a working product each iteration. You should take care to allow for concurrent development and greater collaboration. These factors enable the iterations to begin as soon as possible by incrementally providing design to vendors.
multi-stage contract
Generally, such contracts are used to initially perform a pilot project to assess vendor capabilities and then assigning the main work to the vendor based on performance on earlier contracts. Like time-and-material contracts, You can use multi-stage contracts to get high-value features developed first and implemented in a working product. Such contracts can be put into effect iteration by iteration and can last as long as both parties continue to derive value out of the association.
target-cost contract
In this type of contract, total costs, including changes, are the joint responsibility of both the customer and the vendor. The customer and vendor will share the additional costs if the actual costs exceed the initial cost estimate. At the same time, if actual costs are less than estimated, both parties will share the benefits. Target-Cost types of contracts allow for greater trust and collaboration, as better performance is beneficial to both parties.
Shared-Benefit contract
Both parties will have a stake in the results. A profit-sharing contract is a prime example of such a contract. Again, with this type of contract, better performance is in the interest of both parties.
The common theme among all four of the above contract types is that they avoid fixing scope initially, enable concurrent development, build trust between customer and vendor, and provide for a way to deal with unpredictable future events fairly and equitably to both sides.
We are at the end of our discussion on Lean Philosophy. We have seen seven lean principles and 22 tools to be considered to put the lean philosophy to work. Despite having origins in manufacturing, Lean has proven to be a foundation for building optimized practices and processes in various situations, and that’s why almost all agile frameworks borrow techniques from it. For the same reasons, even startups see Lean as a valuable guiding force for their success. Lean is also Internalizing these techniques will help you immensely to achieve remarkable outcomes.
ALSO READ
Fundamentals of Agile: A Simple Yet Comprehensive Guide for Beginners
What Is Scrum? A Deep Dive Into The Framework And Its Successful Adoption (Part I)
What Is Kanban? A Capable First Step Into Agile World
DOWNLOADS/EBOOKS
