lean software development software development core activities processes requirements design engineering construction testing debugging deployment maintenance paradigms and models agile cleanroom incremental prototyping spiral v model waterfall methodologies and frameworks asd devops dad dsdm fdd iid kanban lean sd less mdd msf psp rad rup safe scrum semat tsp up xp supporting disciplines configuration management documentation software quality assurance sqa project management user experience practices atdd bdd cco ci cd ddd pp standup tdd tools compiler debugger profiler gui designer modeling ide build automation release automation infrastructure as code testing standards and bodies of knowledge babok cmmi ieee standards iso 9001 isoiec standards pmbok swebok itil glossaries artificial intelligence computer science electrical and electronics engineering vte lean software development is a translation of lean manufacturing principles and practices to the software development domain adapted from the toyota production system it is emerging with the support of a prolean subculture within the agile community lean offers a solid conceptual framework values and principles as well as good practices derived from experience that support agile organizations origin the term lean software development originated in a book by the same name written by mary poppendieck and tom poppendieck has resulted in such concepts being more widely accepted within the agile community lean principles lean development can be summarized by seven principles very close in concept to lean manufacturing principles eliminate waste amplify learning decide as late as possible deliver as fast as possible empower the team build integrity in see the whole eliminate waste lean philosophy regards everything not adding value to the customer as waste muda such waste may include partially done work extra processes extra features task switching waiting motion defects management activities industry research revealed these software development wastes building the wrong feature or product mismanaging the backlog rework unnecessarily complex solutions extraneous cognitive load psychological distress waitingmultitasking knowledge loss ineffective communication in order to eliminate waste one should be able to recognize it if some activity could be bypassed or the result could be achieved without it it is waste partially done coding eventually abandoned during the development process is waste extra processes like paperwork and features not often used by customers are waste switching people between tasks is waste waiting for other activities teams processes is waste motion required to complete work is waste defects and lower quality are waste managerial overhead not producing real value is waste a value stream mapping technique is used to identify waste the second step is to point out sources of waste and to eliminate them wasteremoval should take place iteratively until even seemingly essential processes and procedures are liquidated amplify learning software development is a continuous learning process based on iterations when writing code software design is a problem solving process involving the developers writing the code and what they have learned software value is measured in fitness for use and not in conformance to requirements instead of adding more documentation or detailed planning different ideas could be tried by writing code and building the process of user requirements gathering could be simplified by presenting screens to the endusers and getting their input the accumulation of defects should be prevented by running tests as soon as the code is written the learning process is sped up by usage of short iteration cycles each one coupled with refactoring and integration testing increasing feedback via short feedback sessions with customers helps when determining the current phase of development and adjusting efforts for future improvements during those short sessions both customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development thus the customers better understand their needs based on the existing result of development efforts and the developers learn how to better satisfy those needs another idea in the communication and learning process with a customer is setbased development this concentrates on communicating the constraints of the future solution and not the possible solutions thus promoting the birth of the solution via dialogue with the customer decide as late as possible as software development is always associated with some uncertainty better results should be achieved with a setbased or optionsbased approach delaying decisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions the more complex a system is the more capacity for change should be built into it thus enabling the delay of important and crucial commitments the iterative approach promotes this principle the ability to adapt to changes and correct mistakes which might be very costly if discovered after the release of the system with setbased development if a new brake system is needed for a car for example three teams may design solutions to the same problem each team learns about the problem space and designs a potential solution as a solution is deemed unreasonable it is cut at the end of a period the surviving designs are compared and one is chosen perhaps with some modifications based on learning from the others a great example of deferring commitment until the last possible moment software decisions could also benefit from this practice to minimize the risk brought on by big upfront design additionally there would then be multiple implementations that work correctly yet are different implementationwise internally these could be used to implement faulttolerant systems which check all inputs and outputs for correctness across the multiple implementations simultaneously an agile software development approach can move the building of options earlier for customers thus delaying certain crucial decisions until customers have realized their needs better this also allows later adaptation to changes and the prevention of costly earlier technologybounded decisions this does not mean that no planning should be involved on the contrary planning activities should be concentrated on the different options and adapting to the current situation as well as clarifying confusing situations by establishing patterns for rapid action evaluating different options is effective as soon as it is realized that they are not free but provide the needed flexibility for late decision making deliver as fast as possible in the era of rapid technology evolution it is not the biggest that survives but the fastest the sooner the end product is delivered without major defects the sooner feedback can be received and incorporated into the next iteration the shorter the iterations the better the learning and communication within the team with speed decisions can be delayed speed assures the fulfilling of the customers present needs and not what they required yesterday this gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge customers value rapid delivery of a quality product the justintime production ideology could be applied to software development recognizing its specific requirements and environment this is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration at the beginning the customer provides the needed input this could be simply presented in small cards or stories the developers estimate the time needed for the implementation of each card thus the work organization changes into selfpulling system each morning during a standup meeting each member of the team reviews what has been done yesterday what is to be done today and tomorrow and prompts for any inputs needed from colleagues or the customer this requires transparency of the process which is also beneficial for team communication empower the team there has been a traditional belief in most businesses about the decisionmaking in the organization the managers tell the workers how to do their own job in a workout technique the roles are turned the managers are taught how to listen to the developers so they can explain better what actions might be taken as well as provide suggestions for improvements the lean approach follows the agile principle encouraging progress catching errors and removing impediments but not micromanaging another mistaken belief has been the consideration of people as resources people might be resources from the point of view of a statistical data sheet but in software development as well as any organizational business people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks people need motivation and a higher purpose to work for purpose within the reachable reality with the assurance that the team might choose its own commitments the developers should be given access to the customer the team leader should provide support and help in difficult situations as well as ensure that scepticism does not ruin the teams spirit build integrity in the customer needs to have an overall experience of the system this is the socalled perceived integrity how it is being advertised delivered deployed accessed how intuitive its use is its price and how well it solves problems conceptual integrity means that the systems separate components work well together as a whole with balance between flexibility maintainability efficiency and responsiveness this could be achieved by understanding the problem domain and solving it at the same time not sequentially the needed information is received in small batch pieces not in one vast chunk preferably by facetoface communication and not any written documentation the information flow should be constant in both directions from customer to developers and back thus avoiding the large stressful amount of information after long development in isolation one of the healthy ways towards integral architecture is refactoring as more features are added to the original code base the harder it becomes to add further improvements refactoring is about keeping simplicity clarity minimum number of features in the code repetitions in the code are signs of bad code designs and should be avoided the complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests having the same versioning synchronization and semantics as the current state of the system at the end the integrity should be verified with thorough testing thus ensuring the system does what the customer expects it to automated tests are also considered part of the production process and therefore if they do not add value they should be considered waste automated testing should not be a goal but rather a means to an end specifically the reduction of defects see the whole software systems nowadays are not simply the sum of their parts but also the product of their interactions defects in software tend to accumulate during the development process by decomposing the big tasks into smaller tasks and by standardizing different stages of development the root causes of defects should be found and eliminated the larger the system the more organizations that are involved in its development and the more parts are developed by different teams the greater the importance of having well defined relationships between different vendors in order to produce a system with smoothly interacting components during a longer period of development a stronger subcontractor network is far more beneficial than shortterm profit optimizing which does not enable winwin relationships lean thinking has to be understood well by all members of a project before implementing in a concrete reallife situation think big act small fail fast learn rapidly these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process only when all of the lean principles are implemented together combined with strong common sense with respect to the working environment is there a basis for success in software development lean software practices lean software development practices or what the poppendiecks call tools are restated slightly from the original equivalents in agile software development examples of such practices include seeing waste value stream mapping setbased development pull systems queuing theory motivation measurements testdriven development trunkbased development since agile software development is an umbrella term for a set of methods and practices based on the values and principles expressed in the agile manifesto lean software development is considered an agile software development method kanban kanban board lean integration lean services scrum development ladas corey january 2008 scrumban essays on kanban systems for lean software development modus cooperandi press isbn0578002140 ries eric september 2011 the lean startup how todays entrepreneurs use continuous innovation to create radically successful businesses crown business isbn9780307887894 