Need advice? Call Now, Schedule a Meeting or Contact Us
The Lean methodology has its origins in automobile manufacturing and its first implementation dates back to the dawn of the 20th century. In the 1990s, however, the Lean concepts began to enter the project management methodologies. Its attractiveness lied mostly in its methods of reducing the risk within projects by reducing and process bottlenecks, working exclusively on things that add value, and starting new work only when it is necessary.
The lean principles of manufacturing were adapted to software development to create Seven Lean Principles:
The elimination of waste it one of the core lean principles and while it may be difficult to imagine the waste within the framework of software development, it can, just as any process, be wasteful. In fact, the lean philosophy considers any activity or process which fails to add value, wasteful. As such, it should be removed.
An example of waste in software development is the time the developers spend on other activities than the one assigned to them. To maximize the productivity of a developer team means to assign work in such a way that they will, at any given time, be productive. This leads to speedy execution of the task as a whole.
While preventing the team of developers from wasting their time in idleness, it is just as undesirable to press the team to work on unnecessary tasks and create unnecessary work for them. Unnecessary tasks lead to the need for more meetings and communication which, on the other hand, creates more unnecessary interaction and leads to more mistakes and misunderstandings.
Amplifying learning is a principle that calls for exploring ideas thoroughly and thinking through alternatives before taking on an action. In software development, it means running integration and unit tests after each build of the new product, not only to ensure that the code is well-written but also for the purpose of learning. Each testing is a way to learn as it provides insights. Also, it leads to seeing the failures and learn from them, to discover the flaws and switch to better approaches.
Another way to learn is by involving the clients in the development process and letting the clients see and test various versions of the product, at the very beginning of its creation. Again, this allows for early detection of possible flaws and a quick refocus on the correct versions or a swift refinement of an otherwise well-created product.
The word “late” may carry an overall negative connotation in itself, deciding late is indeed one of the principles of successful project management, according to Lean. Deciding as late as possible goes, in fact, hand in hand with the amplified learning process. If the team allows the client to take part in the initial creation process, chances are that the client will opt for the latest, refined, and modified version of the product. The prototype, therefore, is rejected and all work done on it goes to waste had the team made their decisions too early in the process.
Therefore, important decisions are to be made not at the outbreak of the development process, but after the data and information is collected. Once all the alternatives are presented to the client and the best prototype is chosen, then the team makes their final decisions as to the details of the product creation.
Contrary to the decision process, the delivery of the final product should be as fast as possible. While the two principles may seem to be in opposition, they complement each other.
Operating by Lean principles means operating in short and rapid iterations without fillers and unnecessary work. The aim is to deliver the basic product fast so that its features can be detected and corrected. This allows for the product to grow fast and reach the desired quality within reasonable time.
This principle is summed in the words of Teddy Roosevelt: “The best executive is one who has sense enough to pick good people to do what he wants done, and self-restraint enough to keep from meddling with them while they do it.” Thus, empowering the team means encouraging the developers to have their say on things they do the best – the software development and allowing them to come up with solutions to satisfy the client requirements.
This principle goes against the traditional management in which the manager leads its team in every step and micromanages every detail of the work they are doing. It breaks the traditional pattern of the manager being seen as un unquestioned authority and portrays the developers as allies, rather than subjected workers. It gives the developers a chance to practice freedom in many aspects of their work, to be in control of the operation, and to boost both their productivity and their morale.
This all-encompassing principle aims at the usage of best practices to avoid errors. The goal here is to build quality products through good documentation, refactoring code to be more efficient, and develop automated testing. It also builds upon the idea from Extreme programming, which is the creation of pairs of developers who serve as a guide to each other and help each other increase the quality of the product while reducing the defects and waste.
Last but not least – the principle of seeing the software as a whole instead of as individual components promotes cohesiveness of the process so it can run smoothly and logically. It is the ability to perceive the individual pieces interwoven together to create a big picture. Without the perception of the whole picture, the process may end up being disjointed and illogical while the developers grow demotivated.
Besides these seven principles, there is a set of other, recommended guidelines, such as outlined in Mary and Tom’s Poppendieck study on software development by Lean principles. These guidelines include encouraging leadership, usage of scientific methods backed by data, and initiation of experiments to obtain them. When put in practice, these guidelines supplement the seven main principles and lead to better and more efficient software creation.
IPM's Certified Project Management Diploma is focused on getting you familiar with the Lean values and principles and other PM skills to advance yourself in managing multiple projects and strategic PMO thinking.
Reference Literature
Poppendieck, Mary and Tom. (2003). “Lean Software Development: An Agile Toolkit“.
We use cookies to ensure you get the best experience of our website. By clicking “Accept All”, you consent to our use of cookies.