Lean vs Agile isn’t the question you should be asking. It is if lean vs agile methodology such as scrum or XP.
In my opinion lean empathizes what Agile set out to do. It is product management at its core. There is no bigger waste than building features that a user won’t use. Lean is focused on addressing this.
These are 9 reasons why as a product manager you should be pushing the team towards lean practices instead of Agile.
1. Outcomes vs Outputs
As a business owner or product manager you want to always be delivering value to the customer. You don’t care about software engineering practices. Its outcomes you want not outputs.
The IT department plays a critical role in the success of your business. You will be investing a lot of money for them to help you deliver strategic plans and revenue for the company. It should be deeply integrated with business functions. How to do this is by having product teams.
When you should use lean is you want to have your development team part of the mission to service your customers. You need to provide them with your problems not requirements. The last thing you want is to spoon feeding the development team requirements as this just leads to poor results. You want the team to be focused on delivering outcomes.
Lean focuses on delivers outcomes
When you should use other Agile methodologies such as Scrum Agile Framework work is when you are outsourcing your software development. You need to realize though what you are doing is staggered waterfall not Agile per se. Scrum gets lost in following the framework vs delivering value. If you want your IT department to be a cost center and think its okay you should read LeanEssays: The Cost Center Trap.
Scrum focuses on delivering outputs
2. Lean vs. Agile Have Same Principles
Lean is actually the most Agile of all methodologies if you look at the principles. I have attempted to map lean principles to agile principles below. There is a comprehensive overlap. Why I favor lean over other Agile methodologies is the acceptance that there is waste in Agile methodologies and we should look at reducing it.
Lean focuses on delivering value to customers faster by identifying and removing waste from a manufacturing process, or (put another way) by reducing lead times through optimization of the value stream. Lean primarily focus is reducing waste. Scrum focuses on user centered product. There are 7 types of waste in lean product development.
Maybe you don’t need a estimation session every week so you have a backlog of story points for the next 18 months. This is why I feel other Agile methodologies hide behind the framework which can quickly turn into a staggered waterfall approach vs agile project management.
- Scrum: An Agile Framework process with ceremonies around small incremental “sprints” of 2-3 work weeks
- Kanban: An Agile Framework that uses a Kanban board to visualize and limit Work in Progress to deliver quicker
- Extreme Programming: An Agile framework that encourages feedback but focused on improving software development practices
- DevOps: Continuous Integration and Continuous Deployment of development work
DevOps is mainly geared towards the first 3 principles of Agile:.
- Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
3. Lean vs Agile Scrum
Lean project management was first crafted by Mary and Tom Poppendieck by taking lean manufacturing techniques and using them for software. The wrote the book “Lean Software Development”, which utilized Lean values, practices, and principles to the software industry.
Scrum is the Agile methodology of choice used by large enterprises. They are utilizing Scrum as a hybrid project management as staged project management vs staying true to Agile principles. Methodologies such as SAFE and LeSS are a high contributing factor to this.
The core idea of Scrum was to release small increments of value to the customers. This works well in small companies. Unfortunately, in large companies, it’s not so easy when you have multiple layers of people acting as the customer. You are reporting and gathering feedback from managers and there is a large disconnect in the entire process.
Scrum has clearly defined ceremonies to enable these 9 principles from Daily stand-ups, planning, sprints, estimation, refinement and retrospectives but these are number 4 to 12 in the 12 Agile Principles.
A lot of these software development processes such as daily stand-ups are great to increase communication. Having retrospectives and review sessions are essentials forums to gather feedback and improve as a team.
A couple of issues I found with Scrum, which I personally found anti-agile were:
- Project managers are only interested in the sprint complete dates,
- Scrum masters see the ceremonies as rules that can’t be broken,
- Business sees burndown charts are seen as the source of truth,
- The development team only care about a feature up to end of a sprint,
- Operations aren’t included in the planning of sprints,
- POs having to reject bugs for at least 3 weeks till next sprint.
The role of Product Owner is one of the main issues with the Scrum framework. They are the linchpin in Scrum. In my opinion the business has a product owner in place to be the project manager to give status updates, the team expect them to be a business analyst being bale to prepare detailed stories and specs. Mary Poppendieck discuses this problem very well.
In a essay published on Mary’s blog she highlights the problem with Product Owners. “There was serious confusion about the Scrum role of Product Owner and its fit with the classic role of Product Manager. In addition to business responsibility, the Scrum Product Owner has the team-facing responsibility of managing the detailed product requirements.”
How she addressed this was comparing to “highly successful vertical markets, there was no Product Owner preparing and prioritizing stories for the development team. Instead, the Product Manager had regular high level conversations with the development team about the general capabilities that would be desirable over the next two or three months. They discussed the feasibility of adding features and the results that could be expected. A real time application was created to show live web analytics of several key metrics that the Product Manager correlated to increased revenue. Then the team developed the capabilities most likely to drive the metrics in the right direction, observed the results, and modified their development plans accordingly.”
Mary Poppendieck
4. Lean Avoids Feature Factories
In theory it might seem they are applying Agile principles but what they are really doing is building endless backlogs and feature factories. John Cutler came up with the term feature factory as he saw some companies become more interested in completing story points than learning what types of functionality users actually wanted. John viewed these organizations as factory workers assembling features without thinking about what they contributed to the product.
I have a similar opinion to John as team leaders are more interested in burndown charts and hitting sprint goals than the business outcome achieved. This is how success is measured. It can be argued other Agile methodologies such as Scrum which are centred around software development teams and processes.
Even though most companies I have worked with, have implemented Scrum, some better than others. There was always a disconnect to actually releasing due to testing and scheduling etc. After reading The Phoenix Project it gave me a new understanding of these struggles but from Ops team point of view instead of the feature team.
Simply because a feature has been “released” from a sprint doesn’t mean that it actually goes “Live” into a production environment. I admit I took for granted the struggles of deploying code into new environments and never really understood the struggles that the development team were protected from.
The Phoneix Project teaches W. Edward’s Deming ‘appreciation for the system’ which highlights the need to ensure the fast, predictable, and interrupted the flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable and secure it service.
Lean project management puts the customer first.
5. Kanban vs Lean Project Management is Based on Toyotas Success
The phrase Lean Project Management is adoption from lean manufacturing which is focused in eliminating waste. Lean Manufacturing methods were developed by Toyota from studying the work process in supermarkets fulfilling stock needs. The supermarkets were able to fill the shelves with just enough product to keep the consumer happy and enough stock to keep shop owner happy.
Toyota wanted to replicate this in their factories so they assigned Taiichi Ohno one of their engineers to implement it. This is in turn created lean manufacturing and the word Kanban was used by Toyota to describe the process. The word Kanban translates to signboard in Japanese ().
When working in a start-up though we avoid this issue by working in teams that have full end to end accountability for delivering business outcomes. The product and tech team are actively reviewing data to make decisions to help deliver the outcomes.
Lean Product Development Explained
Product management is critical to developing the right thing at the right time for the right people.
6. Lean Recognizes 7 Types of Waste
The 7 types of waste in lean product management include task switching, defects, waiting, extra processes, not finishing work.
I feel lean is the perfect Agile methodology if you want to be a user centered organization. At its core its about providing value to the end user. The core lean tools such as Kanban Boards, Value Stream Mapping, A3 for PDCA (Plan-Do-Check-Act), Devops as Software development all incorporate lean thinking.
7. A3 for Easy Planning and Analysis
A3 a structured way to learn about a dilemma and explore options for improving the situation. It can include value stream maps.
8. Kanban Framework for Improved Ways of Working
The core principles of Lean Product Management were created by Mary and Tom Poppendick inspired by Lean manufacturing. Lean manufacturing used Kanban boards such the Toyota system.
Kanban is a framework for managing flow of materials or information. Kanban matches amount of work to a teams capacity giving them more flexible planning options, faster output and transparency throughout the development cycle.
Kanban has one main tool the Kanban Board, which augments the traditional Iteration Backlog with additional detail by including the development steps/processes as well as introducing work limits per queue.
- Small tasks that don’t warrant a story.
- Support team as it prevents overloading team members with work and they can just pick up next tasks on top of the queue.
Even though Kanban doesn’t define a full agile life cycle it has gained popularity as it replaces the Iteration Backlog and can adapt to change a lot quicker. It is also been used by companies new to Agile as it can fit in with their current process without much interruption.
Most project can be viewed as a process to achieve a desired result. Kanban is a tool for managing the process and manage the optimal flow of work within the project. There are 3 rules to implement Kanban..
Rule #1: Visual Workflow
A visual representation of the process is key for success especially with more complexed processes. To create the visual representation you need to determine the workflow of the tasks to complete the project. For software development a simple example workflow would be…
Analyse -> Design -> Develop -> Test -> Release
These would then get their own columns in the Kanban board. After you have created the Kanban board you need to set limits to each column.
Rule #2: Limit Work in Process (WIP)
The Work-In-Process (WIP) is the limit of tasks for each column. The concept is that only a number of things can be worked on at the same time to be done well. There is always an optimal amount of work that can be processed regardless of team size, organization etc. The lower the WIP the quicker bottlenecks or pain points in the process will be revealed but if too low the team will ignore them and learn nothing. Moderate WIP limits is a good compromise with a resilient team to the new process.
Rule #3: Measure and Improve
Similar to other Agile Methodologies improving the process is a constant process and based on metrics. The key metric in Kanban is the WIP and the manager should be focused on looking for the optimal WIP to get the team to reach their maximum potential. Another metric that is brought to light from Kanban boards is the cycle time to complete a task and also the manager should be looking to reduce.
9. Devops for Frequent Software Releases & Quicker Feedback
DevOps goal is shortening software delivery cycles and improving the stability of deployments.
The Agile Admin’s popular blog post, What is DevOps?
“DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.”
defining DevOps is chronicled in The DevOps Handbook,
“DevOps is the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others. Other valuable contexts that DevOps draws from include high-trust management cultures, servant leadership, and organizational change management. The result is world-class reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability through the technology value stream, including Product Management, Development, QA, IT Operations, and Infosec.”
What feels like a departure from process is merely the continual refining of a process
Some of the key management practices of Lean management and monitoring include:
- Lightweight change approval processes. “Teams that reported no approval process or used peer review achieved higher software delivery performance…teams that required approval by an external body achieved lower performance.” (Accelerate)
- Monitoring. Use data from monitoring tools used for applications and infrastructure to inform daily decision-making.
- Work in Progress (WIP) limits. Keep teams efficient and focused, increasing throughput, by minimizing the different projects in process for a particular team at a given time.
- Visualizing work. Make use of a Kanban board or similar method to show work moving through development stages.
As my experience with DevOps is only starting I don’t have any pet hates like I do for Scrum but Scrum does help build teams very well so with this and a new focus on continuous delivery and integration coming from Devops it might be the perfect match. I was always in favour of a Scrumban approach so maybe in the future, this might be the happy medium combined with a CI/CD release process.