FPO

Archive for the ‘Value Proposition’ Category

Agile Philosophy: Is Lean the Missing Link? (Part 2)

without comments

Birthplace of Lean Manufacturing

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.

Written by Drew Jemilo

April 2nd, 2009 at 7:23 pm

Posted in Lean, Value Proposition

Agile Philosophy: Is Lean the Missing Link? (Part 1)

without comments

You’ve likely read the Agile Manifesto, the values which were developed by representatives from Extreme Programming, Scrum, DSDM, Feature Driven Development, Crystal, and other alternatives to the heavy, document-driven Waterfall methodology.

Agile Minds, Lean Thoughts

Agile Minds, Lean Thoughts

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The Manifesto statements offer traceability to many of the Agile management practices. If we use Scrum management practices for our examples, we can make the following connections:

  • The daily 15-minute Scrum meeting with the team standing around the low tech task board supports the value of individuals and interactions over processes and tools
  • The Sprint Planning meeting, where the light-weight User Stories are transformed into a shared understanding of the features to be implemented, supports the value of working software over comprehensive documentation
  • The application of “good” versus “good enough” in order to deliver on time supports the value of customer collaboration over contract negotiation
  • The re-prioritization of the Product Backlog before each Sprint Planning Meeting supports the value of responding to change over following a plan

Agile Values vs. Business Value

Though the Manifesto articulates the values that provide the foundation for the “what” and “how” of Agile, it doesn’t answer the question “why.”

Why are individuals and interactions more valuable than processes and tools? Many people could argue that individuals are inconsistent, their memories are fallible, and their interactions are unpredictable. Shouldn’t defined processes bring consistency and tools record decisions which may otherwise be lost or reinterpreted?

How do we move from Agile values to business value?

Finding the “why” in Lean

When the Agile Manifesto was developed in 2001 at the Snowbird Ski Resort in the Wasatch Mountains of Utah, Mary and Tom Poppendieck had not yet released their book on Lean Software Development.

Lean Software Development draws heavily from the rules of the Toyota Product System, later called Lean Manufacturing. Simply put, it is a time-tested method which focuses on providing more value with less work.

More value with less work. Now that’s something which any CEO could support.

In Part 2, we’ll map the value-driven rules of Lean Manufacturing to Agile management practices.

Written by Drew Jemilo

March 30th, 2009 at 2:33 pm

Posted in Lean, Value Proposition