Within the context of product development and manufacturing, Lean management is essentially an efficient means of controlling production costs and maximizing profit over the product life cycle while avoiding and reducing defects and scrap (wasted effort, time, and resources). Waste typically occurs in the form of excess inventory, production, resources, or processes. This is valid for the manufacturing industry but is applicable to other industries as well, though the terminology may change.
There are eight areas of waste defined in Lean management:
Transport: Moving people, products, and information
Overproduction: Producing more than is immediately required
Waiting: For parts, information, instructions, resources, and equipment
Inventory: Warehousing parts, pieces, and documentation ahead of requirements
Skills: Underusing staff capabilities or delegating tasks beyond scope and training
Overprocessing: Stricter tolerances or higher-grade materials than are necessary
Defects: Rework caused by poor planning and unclear documentation
Motion: Wasted movement of personnel due to disorganization of parts, workstations, tools, and other components (bending, turning, reaching, lifting, absence from workstation)
In Agile, these eight identified wastes from Lean are addressed throughout the life cycle of the product development. Let's look at them one by one:
It is imperative that the Agile team is on top of its game through collaboration. Without collaboration, the projects and ultimately the team falls apart. All protocols in Agile point to equal collaboration across the board within the team, with an equal division of responsibilities. Basically, there should not be one person doing less than another, or pulling the weight for others. If you see that happening in your team, then the product review is an appropriate time to discuss these issues and create an action plan to address all concerns. Your team's product owner and ScrumMaster should do everything possible to remove impediments and get the team on a collaborative and constructive path.
In Agile, at the beginning of the product development, a product backlog is defined and put together. This addresses what is to be built, creates a road map for development, and determines how much has to be built and when. Retrospectives, releases, and sprint planning address concerns pertaining to the product development life cycle. The scope is flexible for each sprint cycle -- identifying what and how much must be built is addressed at each iteration of sprint planning, review, and retrospective. This helps track what is being built, how much is completed, and what is still left to be built or enhanced. And if the team's activity slows down, key momentum is lost, so production also slows down. When the development team has more information through collaboration, more user stories can be pulled from the backlog queue to be developed and delivered.
Continuous development and delivery
One of the key features of Agile is the development of the team habit of continuous engagement. If the teams are not engaged in this fashion, then either they are not practicing Agile or the agility focus within the team is lost and not on track. This requires the process to be fixed sooner rather than later. Essentially, there is no waiting period for information, instructions, or infrastructure. This may seem harsh for external dependencies, but the focus should be development and continuous value delivery to the business, regardless of what (or how many) factors are involved. At roadblocks, both the ScrumMaster and product owner play crucial roles in making sure continuous development does not stop or slow down.
Paired resources in a cross-functional team
Agile promotes one team with a varied skill set (at least, that should be the goal) and provides the opportunity for each person to learn various facets of development within that team. Therefore, the existence of a cross-functional team is important and should allow for the strategic use of skills and talent of team members, the pairing of resources with their experience level (e.g., less experienced with advanced), promoting self-ownership so tasks are self-identified and executed, and developing a learning culture through the cross-functionality within the team.
Agile teams are not perfect, and they learn and evolve through their experience over time -- sprint after sprint. Therefore, the notion of having the team estimate its work efforts accurately is completely wrong. The team learns through its sprint executions, based on team members' prior product, work, and development environment experience. There are several techniques suggested during sprint planning and execution, but none of them can carve the estimates in stone and move forward with them. The whole definition of doing the projects the Agile way is to embrace the flexibility and learning opportunities that result when the team self-motivates and self-improves over each sprint cycle, reaching a higher velocity over the product life cycle.
One way to look at defects within Agile is from the perspective where the large portion of efforts are spent on verification and validation throughout the product development life cycle. Without such a process in place, the output from sprint cycles would contain a high business value without the finished product for the business users. The quality of the code and the quality of the product being built are both important within Agile. The product team spends a significant amount of time in unit, integration, regression, and user acceptance testing through automated means and through continuous delivery. Daily builds are as important as writing the code every day and making it useful for the sprint output.
ScrumMaster and product owner -- shared importance
Both the ScrumMaster (SM) and product owner (PO) play crucial roles in Agile, and this is equally matched by the team through its continuous development work. The SM's role is that of facilitator and caretaker of the team, one whose job is to remove impediments and keep the team focused and on track and keep its morale high for continual, effective levels of productivity. The PO, as the owner and guardian of the actual product that the team is building, retains and shares an awareness of the real world and an awareness that what is being produced is worthwhile, relevant, and acceptable.
Lean mission statement
Since Lean's "mission" is to maximize value and minimize waste, the product development team's focus should be on processes that increase value and foster active, targeted engagement of each and every team member. Additionally, the focus should be on the continual improvement of processes with the ultimate goal of value delivery to the customer at the forefront -- essentially adopting the Lean mind-set. New thinking is Lean thinking; old, wasteful ways of conducting business development are not only outdated but wasteful.
Most people are familiar with Toyota's emergence from a small automobile manufacturer to one of the world's largest. How did they do it? Through the adoption of Lean principles and philosophies. The company is well known for its product development practices that identify waste and remove impediments, delivering customer value. But as stated earlier, Lean principles don't apply just to manufacturing. Many different types of organizations recognize their value and incorporate these principles into their own business acumen.
Core Lean principles recognize the value of simple "on-demand" building, accurate performance metrics, and continuous improvement of processes and resources that add value to the product and reduce waste. Before implementation, materials, resources, and information are examined, compared, and mapped. "Who," "what," and "how" are formalized, and the vision of the final product is set, giving a clear picture of the final product, the customer's expectations, and a "same page" agreement of all teams and team members.
There are many Agile principles springing from Lean that, applied eloquently, help businesses achieve the desired results the right way, providing that the implementation of Agile within the organization is done with a strict adherence to Agile methods and guidelines. Any attempt to bend the method or apply only some Agile principles here and there never produces the desired results. This can cause these businesses and technology departments in general to question whether Agile really works for them, or if it is/was the right choice. This makes having experienced Agile coaches as part of the implementation and execution team essential. The Agile coach's role as guide, mentor, and coach directs the team and business in the right direction and helps complete the Agile journey in the correct, appropriate, and value-added way.