|
LEAN
THINKING MEETS SOFTWARE
By Frode L. Ødegård, President, Lean Software Institute
The Lean philosophy
can be stated as follows: only expend cycle time and capital on
that which directly contributes value to the customer. Everything
else is considered waste. In software development, as much as 95%
of the cycle time and 80% of the development efforts are NOT value-added
from the customer's perspective.
Lean began at Toyota, which is able to develop new car models four
times faster than its competitors and with better quality. In this
article, we discuss how the Lean philosophy can be adapted for software
product development. We will also provide some hints on how software
executives can get started with a Lean initiative. Business results
from a Lean Transformation include significant cost savings, improved
quality, and a dramatic reduction in time-to-market.
Lean companies mobilize their people to design product architectures,
teams, and processes to maximize customer value and remove waste.
This is a never-ending and aggressive quest for perfection. Team
rewards are linked to actual bottom-line results achieved. Improvement
ideas from other teams or from other organizations are quickly disseminated.
After internal progress is made, a Lean initiative can be expanded
to cover the entire value chain, with multiple enterprises helping
each other. This results in improved customer and supplier intimacy,
and higher profitability for everyone. Lean can complement a software
outsourcing initiative, and it can help harvest business value from
merger integration efforts.
Everything in Lean flows from five key principles: Value, Value
Stream, Flow, Pull and Perfection. Let’s look at each of these
and see what they mean for software development.
Lean Principle #1: Value is defined by the customer
Many product managers do not really understand how the customer’s
business makes a profit. The justification for a product feature
should be that it helps the customer’s bottom line. Anything
that does not directly contribute value to the customer is waste.
Common sources of waste in software development include: features
that don’t add value, defects (rework and testing), unnecessary
paperwork, waiting, unnecessary movement and handling of people
and components, waste of human talent, unused metrics, and improper
use of software tools.
Lean Principle #2: Learn to see your Value Stream
A value stream is the set of activities required to develop a product.
It may involve multiple processes, teams, and departments. By carefully
analyzing the value stream, we can identify waste and develop remedies
to remove it. This is done using Value Stream Mapping, which
involves a cross-functional team uncovering wasteful activities
and cycle time bottlenecks.
Because the value stream involves everything the organization does
to develop products, we avoid looking at individual functional departments
such as Engineering and Marketing in isolation. In contrast with
traditional approaches to performance improvement, Value Streams
allow us to see product development as an integrated whole.
Advanced practitioners of Lean work with their partners to address
the extended value stream, which includes the entire supply chain.
For example, an outsourcing provider and its customer can cooperate
to improve the economic performance of their common enterprise,
avoiding local optimizations which fail to address real bottlenecks.
Lean Principle #3: Flow – focus on travel time, not load
size
The flow principle is about making effective use of cycle time.
In a typical organization, only 1/3 of the 24-hour day is spent
on developing the product, and only a small fraction of that time
is spent on work that’s value-added from the customer’s
perspective. Aside from rework, unnecessary work, and unneeded features,
much of the waste comes from waiting. Because of the way many companies
organize their product development process, a lot of time can be
spent simply waiting for an intermediate work product that is being
completed upstream.
Consider the cycle time lost because one is waiting for all of the
requirements to be defined before design work can start, or for
all the components to be designed before code can be written. The
result of working in big batches is that we get large work queues
with partially completed work. Partially complete software constitutes
inventory, which is a form of waste. Software inventory clogs
up the development pipeline, increases lead-time, and ties up valuable
cash. The financial consequences can be devastating.
Smaller batches of work lead to less inventory. Since all of the
work queues are smaller, less cycle time is lost due to waiting. This
is why iterative development is faster than the traditional water-fall
approach. However, this requires a significant change of perspective. We
are no longer so interested in how busy we are keeping our people.
Instead, we are primarily interested in the speed with which work
can flow through the value stream and produce value for the customer.
The flow principle has important implications for the way we design
product architectures, product development processes, and manage
development projects. The process must operate on small units
of customer value—requirements—and use small iterations
to produce partial deliverables that can be validated. Metrics
will become more important, not less, because they allow us to track
progress and quickly address bottlenecks to progress. To be
effective, however, the metrics must be directly linked to flow,
to customer value, and to bottom-line outcomes.
Because of the high velocity of lean software development, careful
architectural design is more important than ever. Architectures
must facilitate rapid change without sacrificing run-time dependability
and performance. Requirements and design specifications must be
clear and consistent to avoid wasting cycle time on rework.
Lean Principle #4: Pull – match production to actual customer
demand
Instead of “pushing” work through the process based on
forecasted demand, the pull principle tells us to only build something
when it is actually ordered by a customer. In software development,
this means we want to “pull” new features through the
process based on real customer demand, not “push” them
from the front based on vague assumptions in fantasy roadmaps. Traditional
plan-driven work is replaced by demand-based work, reducing inventory
and improving our ability to react very quickly to customer needs.
Imagine redesigning your product development process by starting
with what the customer pays for and going backwards to determine
how to make it. Only something that contributes to what the customer
pays for would be put into the process. Chances are that many
of the intermediate work products currently produced could be eliminated.
The same goes for product features that do not add demonstrable
value for the customer.
Lean Principle #5: Strive for perfection on all levels
Lean companies provide teams with the skills to relentlessly improve
profitability by avoiding waste in their products and processes. Significant
rewards are provided for making quantifiable improvements in quality,
throughput, and customer satisfaction. Open-book metrics are tied
to financial performance show how teams are doing. To encourage
a higher rate of improvement, development teams can be engaged in
friendly competition, but they should be required to share their
innovations on a regular basis.
Performance improvements can and should go beyond departmental boundaries. Product
development teams should be cross-functional, thus eliminating wasteful
work queues between Marketing, Engineering, Support, and Quality. Instead,
the entire company can be reorganized horizontally around its value
streams. Hierarchical layers can be reduced significantly—the
purpose of functional departments such as Marketing, Engineering,
and Support should be to provide basic infrastructure and coordination
for teams. Most employees would belong to cross-functional
teams tied to productive value streams.
If a purely horizontal organization seems too daunting, a less radical
step is to appoint Value Stream Managers, a technique used by Toyota
to give managers responsibility for the performance of a horizontal
value stream. Value Stream Managers coordinate improvement efforts
across team and departments, thus avoiding local optimizations that
do not address real bottlenecks.
For continued performance improvement, the company has to improve
its ability to harvest, create, and share knowledge. This can
be done on several levels. Within teams, try cross-training team
members and occasionally switching roles. Rotating people between
product teams can also be very helpful. For additional learning
across teams, consider establishing groups for learning and development
in specific areas such as Customer Relationship Management, Software
Design, Usability, Finance, Strategy, Lean Thinking, and Team Leadership. Such
groups should combine ideas from other companies with lessons learned
from past and current projects.
How to get started
For executives, the best way to get started with Lean is hands-on
experimentation. Once you have reached a certain familiarity with
the ideas in this article, your first step is to identify your software
value streams and select one for a pilot. Get your functional managers
together and map the chosen value stream, thus developing a shared
view of where there is obvious waste in the value stream and what
to do about it. Define your future stat—- what you want the
value stream to look like in 30-60 days. As you begin implementing
your changes and gain some initial experience, consider how to organize
your teams, how to educate them, and how to design new incentives
for continuous improvement. You may be impressed by your initial
improvements, but we can guarantee that you will only have scratched
the surface.
Conclusion
Lean Software Development provides a management philosophy and a
set of techniques for designing software value streams. These techniques
enable us to select designs, tools, methods, and organizational
structures based on fitness for purpose. That purpose is to produce
value for the customer with minimum waste for us. There is a wonderful
supermarket of tools, methods, and techniques from decades of progress
in software engineering management. Lean does not invalidate or
validate any of these. Instead, it gives us the wisdom to shop wisely
and employ just the right combination of remedies needed to maximize
value and minimize waste.
About the Lean Software Institute
Frode L. Ødegård is a frequent lecturer and writer
on software engineering management, and the author of a forthcoming
book on Lean Software Development. He is the Founder and Chief Executive
Officer of Ødegård Labs, Inc. as well as its new spin-off,
the Lean Software
Institute. The mission of the Lean Software Institute is to
help organizations achieve breakthrough bottom-line results by implementing
Lean Software Development. For more information about Lean Software
Development, contact Frode at (858) 722-4476 or frode.odegard@leansoftwareinstitute.com
|
