FPO
Archive for April, 2009
A Full-Bodied Agile: Lean, Scrum, and XP
Agile’s Head: Lean

A mind to know, two hands to act
In two previous blog entries, we saw how Lean Software Development, with roots back to Lean Manufacturing, can provide the values which derive the underlying business value. In some ways, it acts as the “head,” telling us the “why” behind that “whats” and “hows” of Agile.
Agile’s Two Hands: Scrum and XP
In addition to the “why,” we also need to know “what” and “how.” I view these as the hands of Agile: one to guide the management practices and one to guide the software engineering practices.
But with so many different Agile methods, how do we choose? Fortunately, the answer is quickly emerging. Scrum has wide market buy-in as an Agile management framework, though it lacks any prescribed engineering practices. Extreme Programming (XP) also has significant buy-in. While XP has a less developed management framework, its strength lies in its quality-driven engineering practices.
Head and Hands: Lean, Scrum, and XP
We previously explored Lean’s values. At a high level, you can see the framework emerge.
|
|
|
This model also allows us to frame Agile readiness and Agile maturity in this way. Is the organization ready to embrace Lean principles? How prepared are teams for Scrum’s management processes? Are the technical infrastructure and software engineering practices ready to become more “extreme” with Extreme Programming?
We’ve already looked at Lean values. In future entries, we’ll dive deeper into Scrum management practices and XP software engineering practices. From there, we’ve laid our foundation for evaluating readiness and measuring maturity.
Agile Philosophy: Is Lean the Missing Link? (Part 2)

Birthplace of Lean Manufacturing
In Part 1, we discussed how Agile values can provide a foundation for Agile management practices. However, through the time-tested rules of Lean Manufacturing, we can learn more about the Agile value proposition.
Mapping Lean Manufacturing to Agile
There are ten rules which can sum up the fundamental practices of Lean Manufacturing in the 1980’s. By looking at both Lean Manufacturing and Lean Software Development, the “why” emerges for the Agile management practices. These management practices can then be traced to the fundamental goal of producing more value with less work.
Getting the Value
Rule 1: Eliminate Waste
In Lean Manufacturing…
- Value Stream Analysis is used to identify all activities in the manufacturing process and the value they add to the final product, not the process. The process is then re-evaluated to find the most efficient way to add the intended product value.
In Agile…
- The biggest waste in software development comes from building features which will be outdated or have little value when finally released. A high priority feature today may be irrelevant in a year. In Agile, the business re-evaluates requirements against changing customer needs before each Sprint so that only the highest priority ones are built.
- In Agile, the User Stories are only frozen for the Sprint (though how they are implemented is negotiated throughout). The business is less hesitant to commit to requirements for the Sprint because they have the opportunity to re-prioritize before each Sprint. They waste less time on forecasting needs and the sign-off process.
- The production of documentation which has no value after the completion of an iteration translates to the scrutiny of document production. Which documents add value to the final product, and which simply support the process? Agile replaces verbose requirements documentation with light-weight User Stories and Validation Conditions. The design is then elaborated through conversation in the Sprint Planning Meeting and the daily Scrums.
- In the Sprint Planning meeting, only the highest priority requirements are broken down into tasks so that time is not wasted on features which may never be implemented. This process is often referred to as “just-in-time elaboration.” Time is not wasted on details which may never be needed.
Rule 2: Minimize Inventory
In Lean Manufacturing…
- Inventory is minimized because it costs money, consumes resources to manage, and becomes obsolete.
In Agile…
- The inventory of requirements is kept at a high level and broken down “just in time” so that unnecessary details don’t need to be managed. During the Release Planning process, high level Epics are created, but not broken down into stories until they are targeted for a release.
- Epics and stories are managed by the business and regularly pruned to eliminate the constant review and re-shuffling of the low or no-value items.
Rule 3: Maximize Flow / Reduce Work-In-Process
In Lean Manufacturing…
- Smaller batches and faster cycle times increase the flow of products from the manufacturer to the customer.
In Agile…
- Short Sprint cycles produce completed units of functionality which can be released to the customer. This allows a smoother flow of features, more frequent customer feedback, and faster responsiveness to change.
Rule 4: Pull From Demand / Decide as Late as Possible
In Lean Manufacturing…
- Pulling from actual demand reduces reliance on and investment in forecasting models. Driving from actual demand is more reliable in volatile environments.
In Agile…
- Freezing requirements at the beginning of a long development process relies heavily on forecasting. By re-prioritizing the Product Backlog before each short Sprint begins, features are driven by actual demand rather than speculation.
- Rather than trying to forecast architecture needs, Agile software engineering practices keep the initial architecture design light-weight and allows for refactoring (reworking of code). This keeps designs simpler, but allows additional architecture elements to be added if needed.
Rule 5: Empower Workers
In Lean Manufacturing…
- Teams are trained in work measurement and improvement techniques. Changes which are driven from the workers “on the floor” improve productivity and morale over changes mandated by management.
In Agile…
- Teams are self organizing, and re-evaluate their processes after each Sprint in the Retrospective Meeting.
- The team is empowered to decide how the stories are implemented. Through User Stories, the Product Owner defines the “who,” the “what,” and the “why.” The “how” is collaboratively developed by the team.
Rule 6: Meet Customer Requirements
In Lean Manufacturing…
- This rule is self-evident, and follows Rule 1 (Eliminate Waste). Manufacturing products which no one buys results in inventory which will never be sold.
In Agile…
- In traditional Waterfall, success is measured by delivering the required features on time and on budget. The delivery of the right requirements is often overlooked. As in Rule 1, the creation of low or no-value features is the most wasteful aspect of software development. Success is measured by delivering only the highest priority features each release in a “good” or “good enough” manner.
- Before the Sprint begins, the business creates validation conditions for each User Story. These validation conditions become the business’ acceptance test criteria. This means coding is driven by tests written by the business, not designs and tests created by the developers.
- During the Sprint Review meeting at the end of each Sprint, the functionality is reviewed with the business to confirm that the requirements have been met.
Rule 7: Do it Right the First Time
In Lean Manufacturing…
- Lean integrates quality at the source, putting controls in place at each step in the process. Before Lean, manufacturing was optimized for product throughput. At the end of the process, tests were conducted and defects were fixed at rework stations.
In Agile…
- Tests are written before code, and defects are fixed at each step in the development process. Barry Boehm observed that it costs 100 times more to fix a problem after release than early in the process.
- In an Agile organizational structure, QA is not a silo. Instead, QA personnel are integrated into each team.
- The change control process becomes simpler and less costly because fewer defects are passed on.
Rule 8: Abolish Local Optimization
In Lean Manufacturing…
- For rapidly changing markets requiring responsiveness over mass production, faster machine change-over is more important than the higher throughput of individually optimized stations.
In Agile…
- Cross training and team collaboration are more important than siloed roles. This allows team members to jump in where needed rather than passively waiting for someone else to complete a task or correct an issue blocking their progress.
- Teams are responsible for delivery rather than individuals. Rewarding individual performance (local optimization) rather than team performance detracts from each persons focus on the overall objective.
Rule 9: Partner With Suppliers
In Lean Manufacturing…
- Companies are able achieved the the greatest efficiencies in their supply chain by reducing the number of suppliers and working with them as partners. The efficiencies gained by trust, collaboration, improved product flow, just-in-time movement of goods, and less supplier turnover outweigh the savings which come from competitive bidding.
In Agile…
- Just as moving parts between suppliers is expensive, so is moving tasks between siloed departments. Agile distributes siloed departments into the teams.
- Integrating the business into each team with daily contact creates a partnership which provides just-in-time elaboration of business requirements and more cooperative relationships. Requirements are not “thrown over the wall” with visibility only at the end of a long development cycle.
Rule 10: Create a Culture of Continuous Improvement
In Lean Manufacturing…
- As Rule 5 (Empower Workers) states, everyone involved in the process has the power to improve it. In contrast, a command and control environments rewards adherence to a strict process. Assuming that processes can continuously be optimized, especially in changing markets, a culture is needed to support continuous improvement.
In Agile…
- At the end of each Sprint, the team conducts a Sprint Retrospective, discussing two simple questions: what went well and what can be improved. Software maturity models such as ISO9000 and the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) reward adherence to strict processes. It assumes that their specific process is right for every situation. Agile assumes that as markets change, requirements change, and the processes to meet those requirements change as well.
Agile: More Value with Less Work
Tracing Agile back to the time-tested rules of Lean Manufacturing, we begin to move from philosophical values to business value.
- Rather than telling a CEO that Agile values individuals and interactions over processes and tools, you can tell her that Agile eliminates waste and creates productive partnerships between all parts of the business.
- Rather than telling a CEO that Agile values working software over comprehensive documentation, you can tell her that Agile speeds up the delivery of valuable functionality to the customer.
- Rather than telling a CEO that Agile values responding to change over following a plan, you can tell her that Agile delivers functionality based on current demand rather than forecasted needs or outdated requirements.
And the list goes on: higher quality, continuous process improvement, and stronger collaboration. Your Agile value proposition is suddenly defined.
