Lean software development (LSD) sometimes referred as to Agile software development is an adaptation of the principles and techniques of lean manufacturing and lean IT for application in the field of software engineering. Adopting the basic principles of Toyota’s Kanban production system, tight-end supporters are gradually emerging as a group among proponents of Agile methodologies.
Origin of Lean Software Development
The term tight software development comes from the book of the same name by Mary Poppendieck and Tom Poppendieck. The book presents the traditional principles of compact production in a modified form, as well as a set of 22 tools, comparing them to Agile practices.
The Scrum framework
The Scrum framework is not a methodology but is mainly used in software development practices as a complete Agile practice. See What is Scrum Methodology.
The involvement of the Poppendieck family in the Agile methodologies community, including the reports of several conferences on Agile software development methodologies, contributes to the wider adoption of new concepts by the proponents of Agile methodologies.
We will talk also about the Kanban development methodology and now is a good time to read Kanban vs Scrum? What Are the Differences Between Scrum and Kanban?
Concise software development can be summarized in several principles, very similar in concept to the principles of compact production:
- Get rid of the unnecessary
- Improve learning
- Decide as late as possible
- Deliver as quickly as possible
- Authorize the team
- Create integrity
- Watch the big picture
The same Agile principles and even more detailed analysis related to Agile project management and product development are presented by the Business Value-Oriented Principles Ltd (BVOP.org) in their BVOP Ultimate Guide and BVOP Agile Guide.
Get rid of the unnecessary
Anything that does not benefit the customer is considered unnecessary, waste (muda). This includes:
- unnecessary code and functionality
- delays in the software development process
- unclear requirements
- insufficient testing leading to repetitions of certain avoidable
- slow internal communication
In order to eliminate surpluses, they must be identified. If one of the activities can be avoided or the result can be achieved without it, it is superfluous. Code written somewhat and abandoned during the software development process is redundant.
Extra processes and functionality that are not commonly used by users is redundant. Waiting for other activities, teams or processes is surplus. Defects and poor quality are surplus. Management levels that do not add real business value are surplus. The value stream mapping technique is used to distinguish and recognize surpluses. The second step is to identify the sources of surplus and eliminate it. These steps should be repeated iteratively until even processes and procedures that appear to be essential are identified and eliminated.
Software development is a continuous learning process with the additional challenges posed by the size of the development teams and the end product. The best approach to improving the software development environment is to improve learning. Defective accumulation should be avoided by performing tests as soon as the code is written. Instead of adding additional documentation or detailed planning, different ideas can be tested by writing code and assembling it. The process of collecting consumer requirements can be simplified by presenting sample screens to end users and taking feedback from them.
The learning process is further accelerated by short iterative cycles – each followed by refactorization and integration testing. Intensifying feedback through short sessions with users helps determine the current development phase and calibrate efforts for future improvements. During these brief sessions, both the customer representatives and the development teams learn more about the specific problem and identify possible solutions for future development.
In this way, the users themselves understand their needs better based on the results of the developers ‘efforts so far, and the developers learn how to better meet the users’ needs. Another benefit of continuous communication and learning between developers and users is the development that focuses on communicating the constraints of a planned solution rather than possible solutions, thus stimulating the birth of the solution through dialogue with the user.
Decide as late as possible
Because software development always involves a certain amount of uncertainty, better results would be obtained by postponing the decision as much as possible so that it could be based on facts rather than uncertain assumptions and expectations. The more complex a system is, the more flexibility and opportunity for change it needs to be provided in it, providing opportunities to delay important and significant concrete commitments to implementation. The iterative approach overrides this principle – the possibility of adapting to changes and correcting errors, which could be very costly if the need was discovered only after the system was officially launched.
The Agile software development methodology envisages empowering users early in the development process, thus postponing critical decisions to a later stage once users have become more aware of their needs. See Agile And Waterfall Methodologies
This also allows for later adaptation to change and prevents costly, technology-dependent earlier decisions. This does not mean that no planning should be done. On the contrary, planning must have and it should be directed to the different options and to the adaptation to the current situation, as well as to clarify the unclear situations by drawing up quick reaction schemes. The valuation of the various options is effective insofar as it is realized that they have a price, but provides the necessary agility to make a decision later.
Deliver as quickly as possible
In an era of rapid technology development, not the greatest but the fastest survives. The sooner a product is delivered without significant defects, the sooner feedback can be obtained and taken into account in the next iteration. The shorter the iterations, the better the learning and communication within the team. Without the necessary speed, decisions cannot be delayed. Speed ensures that the actual needs of the user are met, not what they needed yesterday. This gives them the opportunity to delay deciding what they really need until they gain more and better knowledge. Consumers appreciate the rapid receipt of a quality product.
Production ideology can be applied to software development just in time, taking into account specific requirements and environment. This is achieved by presenting the required result and enabling the team to self-organize and distribute the tasks so that the necessary for an iteration is achieved. In the beginning, the user provides the necessary input requirements. They can be designed quite simply, such as small maps or stories, with developers evaluating the time it takes to implement each card. Thus, work organization becomes a self-evolving system – every morning during a work meeting, each team member takes stock of what has been done yesterday, what is to be done today and tomorrow, and receives the necessary information from their colleagues or the user. This requires transparency of the process, which is also beneficial for team communication.
Another key idea in Toyota’s Kanban production system is set-based design. For example, if a new car braking system is required, solutions to this problem can be developed by three teams at a time. Each team studies the problem area and develops a potential solution. If it is considered inappropriate, its development will be terminated. At the end of the period, the surviving designs are compared and one of them is selected, possibly with some modifications perceived by the others – a great example of delaying the final decision until the last possible moment. Software developments can also take advantage of such practices to minimize the risk of full advance planning.
Authorize the team
The traditional belief in most decision-making companies is that managers tell workers how to do their jobs. In Work-Out, the roles are reversed – managers are learning how to listen to developers so they can better explain what action to take, and come up with suggestions for improvements. The tight approach supports the aphorism of “find good people and let them do their own thing”, encourages progress, catches errors and removes obstacles, but does not manage at the micro level.
Another misconception is that people are viewed as resources. People can be a tool in terms of a spreadsheet, but in software development as well as in any organizational activity, people need more than a list of tasks and the assurance that they will not be disturbed while performing them. People need motivation and a higher purpose to work for – a goal within reality, with the assurance that the team can choose their own contributions. Developers must be given access to the client; the team leader should provide support and assistance in difficult situations, and ensure that skepticism does not ruin the team spirit.
The customer must have a thorough experience with the system – this is what is called perceived integrity: how the system is advertised, delivered, installed, accessed, how intuitive its use is, how much it costs, and how well it solves problems.
Conceptual integrity means that the individual components of the system work well together, as a whole, with a balance between flexibility, maintenance, efficiency and responsiveness. This can be achieved by understanding the scope of the problem and solving it at the same time, not consistently. The necessary information is obtained in small pieces – not in a huge document, preferably face-to-face communication rather than written documentation. The flow of information must be constant in both directions – from client to developer and vice versa, thus avoiding the large amount of stressful information after long development in isolation.
One of the best ways to achieve a complete architecture is through code processing. As more features are added to the original version of the code, it becomes more difficult to add further enhancements. Code processing preserves the simplicity, clarity, minimal amount of features in the code. Repeats in the code are signs of poorly written projects and should be avoided.
The complete and automatic development process must be accompanied by a complete set of automated tests by developers and clients that have the same version, synchronization and semantics as the current state of the system. Finally, integrity must be verified through a comprehensive test to ensure that the system does what the customer expects it to do.
Automated tests are also considered part of the manufacturing process, so if they don’t add business value, they are superfluous. Automated testing should not be an end in itself, but rather a means of reducing defects. Similar approaches apply to Kanban methodology that is described as an Agile methodology as well.
Watch the big picture
Software systems today are not just a collection of parts, but also a product of their interactions. Defects tend to accumulate in software through the development process – by breaking down large tasks into smaller ones and by standardizing the various stages of development, the root causes of the defects must be discovered and eliminated. The larger the system, the more organizations are involved in its development and the more parts of it are developed by different teams, then the more important it is to have well-defined relationships between different suppliers in order to obtain a system with smooth component interaction. With a longer development period, a strong network of subcontractors is much more useful than short-term profit optimization, which does not allow for long-term relationships.
The Lean approach must be well understood by all project members before being applied in a specific, real-world situation. “Think big, act scrupulously, break fast, learn fast” – these slogans summarize the importance of understanding the realm and the appropriateness of implementing lean principles throughout the software development process. Only when all lean principles are applied together, combined with a good understanding of the work environment, is there a basis for success in software development.
All these product development and optimization practices are inspired by the Kaizen system and the 20 keys of Workplace improvement of the Japanese author created the Kaizen rules we know today. Reference: Kaizen: 20 Keys to Workplace Improvement explained with examples.
Practices for tight software development
Practices for tight software development, or as they are called by the Popendique “tools”, are implemented slightly differently than their equivalents in an Agile software development methodology, but there are direct parallels. Examples of such practices include:
- Noticing surpluses
- Value stream mapping
- Set-based development
- Pull systems
- Tail theory
- Some of the tools quite naturally relate to an Agile methodology.
- Workcells, for example, are implemented in an Agile methodology through mixed teams.
- Yasuhiro Monden (1998), Toyota Production System, An Integrated Approach to Just-In-Time, Third Edition, Norcross, GA: Engineering & Management Press, ISBN 0-412-83930-X.
- Mary Poppendieck, Tom Poppendieck (2003), “Lean Software Development: An Agile Toolkit”, Addison-Wesley Professional, ISBN 0-321-15078-3
- Ladas, Corey. Scrumban: Essays on Kanban Systems for Lean Software Development. Modus Cooperandi Press, January 2008. ISBN 0-578-00214-0.