Over the past couple of decades, Agile and Lean have been steadily gaining popularity in various fields and industries. People are having lots of discussion on agile and lean, and trying to compare the differences and benefits. By learning what is agile and what is lean, you may find that they have a lot of philosophies and principles in common such as trust, simplicity, fast delivery, rapid feedback from clients, respect for people and the optimization of the whole. There is an opinion that Agile itself is a lean way to approach the software development lifecycle. Understanding how Lean runs in Agile is a very interesting discussion.
Lean comes from Lean Manufacturing. The core idea is to eliminate waste by reducing non-value-added activities. There are many tools and techniques that lean employs to support the principles, and some of them were adapted to software development by Mary and Tom Poppendiecks back in the 2000’s. The roots of Agile lie deep in the concept of Lean.
In this article, I’d like to talk about how we can see agile through the lean lens using some examples.
- “Eliminate Waste” in the Agile Manifesto
Eliminate Waste is a major principle in Lean. In software development, there are seven wastes defined by Mary and Tom Poppendieck including partially done work, extra features, relearning, hand-offs, delays, task switching and defects. In consideration of these wastes, Agile’s manifesto uses principles, roles, ceremonies, artifacts and practices to minimize them.
- Partially done work
Scrum’s emphasis on delivering as quickly as possible indicates that they try to automatically avoid Partially Done Work. The Role of the Product Owner is defined to prioritize user stories and collaboration so everyone on the team can have a clear understanding on the user story and what goes first. This reduces the possibility of the story remaining incomplete at the sprint end. Plus, to avoid underestimating tasks and leaving tasks unfinished, sprint planning activity encourages the team to have a detailed discussion of user stories and technical complexity before estimates are determined.
- Extra Feature
In Scrum, the product owner is authorized as a project’s key stakeholder to provide the product vision and lead the team to complete the top of the product backlog. This is done to prevent the team from creating more than what is being asked from the start.
- “Just In Time” principle in Agile with Scrum Board
When practicing Scrum, a Scrum board will be created to make the sprint backlog visible by putting it on the board. The progress is visually displayed to the team allowing everyone to see which tasks are in the to-do list, which are in progress and which are done. As you can imagine, visualizing this methodology is very much like a Kanban board.
In the lean world, “Just in time” is a major principle. Agile today can leverage these same JIT principles by matching the amount of work in progress (WIP) to the team’s capacity. Scrum can limit work in progress by enforcing the simple rule that the Product Owner decides what gets built and the team decides how much gets built. The velocity of the team becomes the work limiting factor for the sprint. Explicitly, Agile teams can also do what the Kanban System does: limit work in progress by setting explicit limits on the number of items that can be in any given queue at any given time, forcing the team to remove the bottlenecks before taking on any new work.
Figure 1.1
- A Lean Thinking Perspective of a Burndown chart. A Burndown chart is popular in Agile to show the work progress against the sprint. Usually the story points or tasks are used to show the completed work per day against the projected rate of completion for the sprint. Sometimes the real burndown varies greatly from the expected burndown. To figure out the reasons and issues behind this, lean techniques with Lead Time and Cycle Time can be introduced. Lead Time is a measure of the time from when an item (story, task, etc) is created until it’s been completed. Cycle time tells you how long it takes a task from start through completion. Figure 1.2 shows the intuitive Perception.
Figure 1.2
To explain how Lead Time and Cycle Time are utilized on a Burndown chart, an example is given below.
Figure 1.3 shows a case where the burndown chart doesn’t burn any story point down from July 22 to July 24. By checking the cycle time and lead time of the user stories, we can find some clues as to why. The context is that the Definition of Done for a “Story Point” can only be taken as complete when it passes the test. By analyzing the Lead Time and Cycle Time of the Test work for those stories, it appears that the Test work is the bottleneck. There is so much reaction time for testing started after it’s created. In Lean, the reaction time is the waste because it doesn’t create any value. So by reducing this waste, the burndown chart can burn down rapidly afterwards, around July 4 through July 28.
Figure 1.3
Agile focuses on satisfying the customer through the early and continuous delivery of valuable software by welcoming changing requirements. It encourages the team to be more effective and efficient. So, when Lean can help those, Agile takes. If you are interested in these topics, below are some articles you may be interested in reading:
Agile as a Lean practice in software development
