When you’re Agile you get Lean by Charlie Rudd, CEO, SolutionsIQ

When you’re Agile
you get Lean
by Charlie Rudd, CEO, SolutionsIQ
When you’re Agile you get Lean
Lean manufacturing (or simply “Lean”) refers to the manufacturing philosophy laid out in the Toyota
Production System 1. By applying this philosophy systematically to the manufacture of cars, Toyota
became the global leader with a brand (except for a recent hiccup or two) nearly synonymous with
Lean integrates each step of the supply chain into a holistic value stream. Waste reduction, a core
tenet of the Lean philosophy, is the act of stripping away (production) waste that occurs in the value
stream while preserving or augmenting the value of the final product as perceived by the endcustomer.
In this white paper, we will explore how the concept of Lean waste reduction has migrated from its
origin in manufacturing to the software development industry through the use of Agile. First we will
explore how different kinds of manufacturing waste have analogs in software development. Then,
after we introduce guiding principles that the Lean and Agile philosophies share, we will discuss Agile
practices that embody these principles in terms that demonstrate how they reduce software
development waste.
The seven Lean wastes
The seven kinds of waste as first outlined by Taiicho Ohno 2, provide a framework to identify and
remove waste from manufacturing. Although software development and manufacturing differ in
important ways, once you start looking for the counterparts of manufacturing waste in software
development it is surprising sometimes how easy they are to find.
Inventory. Inventory includes all parts and materials that have been purchased and are waiting
to be used. It also includes work-in-process (WIP). WIP is everything that is being worked on
that is not yet ready for shipment or sale. Inventory and WIP lead to waste because by
definition they tie up resources that are not yet able to generate a return. In addition, the
greater the inventory, the greater the risk of obsolescence, loss and write off.
Inventory in software development. In knowledge work such as software development, we
can think of inventory as being maintained in documentation and in non-deployed software.
Software work-in-process (WIP) is all activity (and therefore expense) subsequent to business
case approval but preceding deployment to production. This includes requirements documents,
project plans, functional and design specifications, source code, test plans, and tests plus the
time to create these artifacts. If a project is a year or more in duration, WIP continues to build
up over the entire period prior to production use. WIP is also tantamount to the accumulation
When you’re Agile you get Lean
of write-off risk for software investments because if the project ends prematurely or never is
delivered, no business value is generated and the WIP investment is lost.
Waterfall software project WIP
Motion. Motion is the movement of people or equipment that takes place in excess of what is
essential to contribute value. To paraphrase the words of Shigeo Shingo, a co-developer of the
Toyota production System (TPS), it's only the last turn of a bolt that tightens it - the rest is just
movement. 3
Motion in software development. Motion in team members is manifested through activities
like travel time, walking to meetings, task-switching between projects and work interruptions. A
30 second work interruption can result in a five-minute think time reset for a developer.
Waiting. Waiting is the delay between steps in production. If an order comes in the mail and
sits in a mailbox, that is the waste of waiting. If an item is assembled, the delay before it is
packaged is the waste of waiting.
Waiting in software development. Examples include waiting for milestone and change request
approvals and sign-offs, waiting for clarifications and elaborations from sponsors and analysts,
waiting for builds and testing to complete, waiting for your turn in meetings and conference
calls, waiting for deployment schedules and architectural and code reviews. Any elapsed time in
excess of what is needed to execute the added value step is a form of waiting. Looked at in that
manner, even the most efficient operations still have a great deal of waiting in principle, leaving
plenty of opportunity for future improvements.
Over-production. Over-production is production ahead of demand. For example, saleable units
waiting in warehouses for buyers are over-production waste. As is the case with WIP, overproduction increases the risk of obsolescence.
When you’re Agile you get Lean
Over-production in software development. Since the model for software use is that one unit
(i.e., one release) is shared by many users (even more so in SAAS environments) and the
physical material cost of a software unit is minimal, over-production is not expressed as
producing units in excess of demand. Rather, over-production in software development occurs
when we build features that are either 1: never or rarely used or that are 2: deployed prematurely.
Over-processing. Over processing is processing done in excess of what is needed. Buffing a
surface a minute longer than is needed for the next step in processing is a minute of processing
waste. Over-processing not only consumes time and resources without adding value; it may
damage or make the end-product less valuable and shorten the useful life of processing tools.
The waste of waiting often leads to the waste of over-processing. Occupying your time with
“busy work” may reduce the emotional distress of waiting by fostering the illusion that at least
something “productive” is getting done, but if it’s not adding any value it’s making things
Over-processing in software development. Over or redundant processing in software includes
low and no value meetings and conference calls, duplicative approvals, redundant reporting,
redundant specifications, over-engineering code and gold-plating specifications, design and
code reviews that don’t result in technical improvements. Overly detailed work breakdown
structures and overly precise estimations are also forms of processing waste.
Transport. Transportation waste is the movement of materials and goods that is not actually
required to perform the processing. It also includes damage to materials and goods that are the
result of transportation.
Transport in software development. Since software
comprises information electronically stored and
accessed, the physically transport of materials or
finished goods is of little concern. However, there is
the analogous waste of translating and handing-off
customer requirements through subsequent phases
such as functional specifications, UML diagrams,
source code and tests. In addition, there is also
information loss (or the introduction of noise) that
damages the information just as finished goods and
materials are sometimes damaged through
Requirements “Lost in translation”
When you’re Agile you get Lean
Defects. The waste of defects refers to the cost of searching for defects, finding them and the
cost of fixing the defects.
Defects in software development. Testing and inspections that do not result in finding bugs are
considered defect waste in software development. Other examples are features that were
implemented but were never requested, inaccurate specifications, production bugs, and
substandard user experience.
Principles and practices: methodology or philosophy?
Methodologies are typically structured as a set of practices defined in terms of rules and procedures.
For someone working within the methodology, knowledge of what principles lay behind the practices is
less important than following the rules and learning the procedures. One can think of the
encapsulation of principles within a procedure as a “benefit” of a methodology: the practitioner can
apply what the experts have previously determined are the best practices without having to think too
With Agile and Lean it’s a different story. Practitioners are expected to understand the principles in
addition to learning the practices. When practitioners agree to adopt Agile practices, they also accept
the responsibility to achieve the goals of the principles embodied within the practices. This is what is
meant by Agile value statements such as “individuals over processes,” “customer collaboration over
contract negotiation,” and “responding to change over following a plan. 4” Process is necessary but not
sufficient to assure high-value outcomes. Much like a squad in battlefield conditions, the agile team
faces a rapidly changing environment and needs to make prudent decisions on how best to apply
guiding principles rather than look up the right answer in a field manual. If outcomes are not ideal, it is
the practitioner’s responsibility to make the necessary adjustments (most often in their own behavior)
to achieve the desired outcomes. When practitioners adopt Agile practices, they are expected to think
more not less.
We can summarize this distinction by saying that Lean and Agile are principle-driven rather than ruledriven. For this reason, many Agile practitioners are more comfortable referring to their community of
practice as a philosophy rather than a methodology.
We will now introduce three principles that Agile and Lean hold in common. Although there are plenty
of other principles that we could discuss, these principles in particular make evident just how much
Agile and Lean share a common philosophy. After each principle we will provide examples of Agile
practices that embody that principle and demonstrate how they reduce software development waste.
1. Deploy as soon as possible
When you’re Agile you get Lean
In essence this means that production should be organized so that tangible value gets in the hands of
the end-customer as soon as possible. The sooner you release the end product, the sooner you receive
a tangible return. The power of this principle increases as uncertainty in the operating environment
increases. Under uncertain conditions, learning as you go is a must. The shorter the release cycle, the
quicker you learn from market feedback. The more frequently you release, the more opportunities you
have to learn to do better. After all, it’s better to fail sooner than later and when you do fail, its best to
learn from your failure.
Corollary: Never defer a fix
Barry Boehm demonstrated many years
ago that the later in the process you find a
defect, the more costly it is to fix 5. The
tonic to this problem, taking steps to
eliminate the cause defects and fixing them
as soon as possible, is core to both Agile
and Lean philosophies. As we will see,
although there is some work you may wish
to defer and even avoid doing entirely, it
would never be at the expense of deferring
fixes that you know need to be made, nor
would you knowingly take a step that might
The cost of deferring a defect5
increase the future incidence of defects. Defects
cost more to fix the longer they fester because more has been invested that now needs to be
reworked or ripped out. In addition, as time goes by, more stakeholders will be affected.
Furthermore, defects that accrue over time snowball in ways that multiplies the damage they
Agile practices
Early and frequent delivery
Early and frequent delivery is defined as shortening the time to deliver the first release and reducing
the time between releases. You obtain the earliest possible delivery by limiting the first release to the
minimal marketable set of features (MMF).
When you’re Agile you get Lean
Early and frequent delivery has the highest impact on
reducing WIP, the most significant form of inventory
waste. By limiting your first release to the MMF, you
also reduce the waste of over-production. Since there
will be plenty of opportunities to release new features
in subsequent releases, the pressure to deploy
features of dubious value in one big bang release is
diminished. Since shortening the release cycle
automatically reduces the size of WIP, the chances
that you will incur waiting and over-processing waste
is correspondingly diminished. Releasing more
frequently means more opportunities to obtain endShort release cycles reduce WIP
user feedback, which reduces defect waste. Defect
waste is also reduced by shortening the times between defect origination, defect discovery and defect
Iterative development and the Definition of Done
If early and frequent delivery is the best way to achieve value, then iterative development is the means
by which we achieve it. Iterative development means completing all the phases of development for a
slice of the total requirements within a very short time box. The emphasis here is on the word
“complete”. Agile teams care about this so much that they create and enforce—the definition of done
(DOD). At a minimum, it is a list of everything that needs to be completed in order to deliver
deployable code. That encompasses the whole range of development tasks from requirements to user
acceptance testing. It also means that the new slice of work is fully integrated with all the work that
preceded it, which at a minimum includes comprehensive regression and systems integration testing.
As Agile teams mature, they extend the DOD to progressively shorten the “last mile” journey to
production. Some Agile teams (especially those deploying to the Web or cloud environments) have
extended their DOD to its logical conclusion by implementing “the capability for push button release”
and deploy code to production after each iteration. In some cases, code may be pushed to production
one or more times each day!
When you’re Agile you get Lean
Short iterations reduce WIP
By completing everything that needs to be done for a small slice of work, WIP is dramatically
decreased. At a minimum, the only work that is not completed during the iteration is code migration
through staging and into production. By focusing on doing the work we can get done within the
iteration, we avoid waiting for inputs that are not immediately available to the production team.
When we use Scrum as our project management framework, waiting is reduced further through the
roles of two people: the ScrumMaster and Product Owner. The ScrumMaster is devoted to removing
obstacles that cause delays to production. The Product Owner is devoted to providing answers about
requirements in a timely manner. Also, the process of the daily Scrum (standup) meeting provides an
atmosphere for all team members to update the entire team on their progress which makes blocking
problems immediately evident. Since the scope of the iteration is fixed on a small set of requirements,
the risk of over-production is constrained. Also, since the DOD enforces a high standard for
completeness, including the completion of all testing within the iteration, the risk of defects is
dramatically reduced. Since a lot of work needs to be completed in a very short period of time, the
team can quickly move to triage mode to throw over board any work that is not critical to getting the
job done. Consequently there is little tolerance for over-processing.
Automated unit testing and high test coverage
The use of third-party automated test frameworks or customized test harnesses enable teams to
implement unit tests at the smallest increment of coding (e.g., a single method, or procedure or
When you’re Agile you get Lean
validation). The ability to easily automate tests while code is being written makes it much more
feasible to achieve the commitment to comprehensively test all source code within the iteration.
Automating the tests reduces the delay of waiting for test results and largely eliminates the need to
defer testing to some later point, reducing WIP. Wait time is further reduced by running the
automated tests as part of frequent automated regression testing. Automating the tests also reduces
the physical motion of the tester by reducing manual testing. Automation also reduces the motion of
the developer by reducing the amount and complexity of future debugging that would otherwise be
necessary when test coverage is not comprehensive. Automated tests naturally reduce the chance of
defects and the more comprehensive and earlier the testing, the smaller the likelihood that bugs make
their way into production. A high percentage of unit test coverage reduces over-processing by reducing
the need and likelihood of redundant acceptance testing. Automated tests also reduce the errors that
are generated from handing code back and forth between developers and testers.
Test driven development
In a nutshell, test driven development (TDD) is the practice of writing the unit test before writing the
code. The test is then run and automatically fails since the code has not yet been written. The task of
the developer is to write the code needed for the test to pass. This sequence is then repeated for the
next unit test and in this way a software object or service is implemented one step at a time. Test
driven development is almost always practiced in conjunction with unit test automation.
We have described how short releases and iterative development reduce WIP at the macro level. TDD
reduces WIP at the micro level. Used in conjunction with just-in-time requirements realization
(discussed later), a task can be fully completed (designed, tested and coded) within sixty minutes of its
definition. The task is small but it is implemented without incurring the waste of waiting and while
keeping WIP small. Since the code is constrained by the tests that precede it, the developer is limited
to writing only the code needed and no more, which reduces the wastes of over-processing and overproduction. And since no code advances without being tested, defects are reduced.
Continuous integration and “don’t break the build”
Continuous integration (CI) is the practice of integrating each increment of code soon after it is written
and successfully unit tested into the code repository 6. This is generally done in an automated fashion
by using a CI server. The CI system not only compiles and builds the code, but executes all the unit,
regression, integration and acceptance tests for the whole build or project. Just as the Definition of
Done can be extended to be more complete, so can the CI system. In addition to unit and system
integration tests, user acceptance tests, performance tests, and code analytics can be added to the CI
system thereby extending the team’s capability and scope for ensuring quality. Extending the scope of
the CI system also reduces the amount of work that would otherwise be performed in subsequent
When you’re Agile you get Lean
testing, staging and deployment phases. In addition, source code can be tagged to make it traceable to
requirements and development activities. The typical minimum frequency for a member of a properly
functioning Agile team to integrate their code is at least once a day. High performing Agile teams
expect to integrate their code many times throughout the day, and often as frequently as every few
minutes. This means that the CI process cycle time needs to be extremely short: otherwise noticeable
wait waste will start to occur.
The mature practice of CI includes an expectation that team members “don’t break the build”. This
commitment is often specified in the team’s Definition of Done. “Don’t break the build” means if an
increment of code generates a “fail” condition as it is being integrated, then the build must be fixed
immediately. This likely involves removing the source code that precipitated the failure. However, it
could also include fixing or changing source code or tests elsewhere in the project, which likely was
written by a different team member. Typically, this means another Agile practice—collective code
ownership (discussed later)—is also employed.
CI reduces WIP by automating the completion of testing and integration so a rigorous Definition of
Done can be maintained as each task is performed. The automation reduces the motion of manual
work and serves up the performance metrics in a form that is directly consumable by the team and key
stakeholders. Waiting for processing to complete is similarly reduced through automation. Since
problems are resolved as they are identified, they don’t compound, which reduces what otherwise
would result in additional processing. Defects are reduced by the facilitation of frequent and
comprehensive testing and the commitment to identify and fix bugs quickly. This practice also makes it
practical for technical quality to be measured in terms beyond bug count to include such items as code
quality, test coverage and user acceptance.
Iteration (Sprint) Review
Iteration (or demo) Review takes place at the end of the iteration and is in effect a mini-user
acceptance test. Business representatives see the new code in action and are able to evaluate whether
or not the value behind the requirements is provided by the implementation. These tangible
demonstrations help business representatives provide useful feedback for the next step in the project.
Iteration Review adds an additional level of assurance that the code as implemented will have practical
business value. Since this is done after every iteration, business approval of the work is obtained early
and frequently, which reduces WIP. The team need not wait for business approval nor need the
business to wait on the team to get a tangible idea of progress. Defects are reduced via the practical
measure of user validation and acceptance.
When you’re Agile you get Lean
2. Defer decisions to the last responsible moment
Avoid making a decision now if you might obtain information in the future that could improve your
decision as long as the delay you incur does not create irreversible damage 7. At first blush this appears
to be the procrastinator’s dream come true; however there is a key difference. Applying this principle
requires that a tradeoff judgment is possible, desirable and made without delay. The power of this
principle increases as the magnitude of uncertainty in the operating environment increases.
Corollary: Do just enough and no more
Agile teams apply this practice to all the activities involved in software development, including
document creation, planning, designing, coding and testing. This means that an individual does
only what is essential to meet the current necessary step and no more. It also means to avoid
duplicating efforts and generating redundant information. What is “just enough” is not always
immediately self-evident, especially when multiple stakeholders are involved. Agile inspired
shops welcome dialog to reconcile different perspectives and establish agreement about how
work is completed and whether or not it should be completed.
Agile practices
Just-in-time requirements and a dynamic product backlog
A just-in-time requirement is the practice of deferring the full elaboration of the requirement until just
before you plan to implement it. Requirements are managed through a dynamic product backlog with
the highest priority items at the top. These are the most detailed because they are next up for
implementation. Lower priority items at the bottom are less detailed. Priorities can be changed, and
requirements added or deleted at any time by the business representative (also known as the Product
Owner in Scrum). Pulling requirements from the top of the backlog, completing their specification and
estimating the effort needed to implement them are the first steps of each development iteration
When you’re Agile you get Lean
Dynamic backlog management
WIP is limited by completing the requirement specification for only the items the team pulls from the
backlog which they intend to complete during the iteration (typically two weeks in length).
Development can start sooner since there is no need to wait for the completion of a full product
specification before development tasks begin. Over-processing and motion waste are reduced because
you avoid documenting requirements that may never be needed or are subject to change before
development begins. Similarly, the cost of changing priority and scope is dramatically reduced. In
addition, since requirements are prioritized, chances are increased that if scope is reduced, the higher
value features will make it into the release. Since scope can be changed at will, better decisions can be
made (and unmade) about which features should be included, thereby reducing over-production. What
does get implemented is less likely to be defective since mindshare is concentrated on a small segment
of work and the work is started right after the team receives the latest and best information available
about the requirements and their acceptance criteria.
Multi-level planning
Multi-level planning is doing the right level of planning and creating plans at the right times. The higher
the level the more summarized the plan. Also, the longer the time frame covered, the less frequent
the planning activity. At one extreme is the product or system vision that may be revisited on a
quarterly basis. The roadmap might be reviewed every month or two and the release plan bi-weekly.
At the other extreme, task defining and planning is conducted on a continuous basis, since tasks are
When you’re Agile you get Lean
often not fully defined until right before they are implemented and may only be minutes in duration.
Multi-level planning emphasizes planning over plans. This means that the detailed planning of work is
integrated into the production process and the bias is toward discussion, collaboration and
implementation rather than maintaining plan documentation.
Multi-level Planning
Since task level planning is limited to imminent work, plan inventories and WIP is kept to a minimum.
Scheduling task level work breakdown structures (WBS) weeks in advance is both unnecessary and is
prone to generating processing waste since scope is frequently adjusted through the use of the
dynamic product backlog. Communicating task schedules between project management and the
implementation team generates motion and transport waste that is reduced through multi-level
planning. Planning at different levels means less waiting on plan approvals and updates between
management and implementation teams.
Business collaboration
Business collaboration is the commitment for the development team and the business representative
to work together on a continuous basis. This commitment extends the engagement beyond the
traditional project approach where most interaction is concentrated at the beginning on user
requirements and then at the end on user acceptance. In many organizations, this can mean that the
business representative co-locates with the team. At a minimum it means that a business
representative is highly available to answer questions, to provide feedback and direction, and
When you’re Agile you get Lean
participate in iteration planning and iteration reviews. As was discussed previously, rather than plan
and specify everything up front, these activities are done incrementally over the course of the project.
Business collaboration reduces wait waste by reducing work delays caused by waiting for answers and
approvals. It reduces WIP by enabling the incremental definition of specifications that in turn facilitates
the incremental delivery of value. Establishing and maintaining ongoing and effective collaboration
leads to better mutual understanding, thereby reducing the cause of many defects. Sustaining an
ongoing dialog about the initiative that is frequently punctuated by joint planning and review of
recently completed work means there is less need to “save the current state” of the project through
interim documentation. This not only reduces motion and processing waste by reducing the need to
generate, revise and review documents, but it also reduces transport waste by reducing translations
and handoffs.
3. Unleash Team Power
Many people say they are pro-team or team players without having a full understanding of how teams
can add value beyond what a collection of individuals might be able to accomplish when working
separately. Beyond maintaining the appearance of political correctness, it’s not always clear what
people mean when they make this claim. Do they really intend to make meaningful commitments to
support team behavior and do they have the knowledge and ability to do so?
Leveraging the power of teams has been a core component of Lean thinking from the start. Agile
practices are designed to establish and support the rapid development of high-powered teams in a
deliberate and disciplined fashion. Organizations that are serious about applying Agile and Lean
principles must make deep commitments to develop and sustain teams. This includes establishing
conditions for teams to form and thrive as well as shifting responsibility and accountability from
supervisors to teams.
Corollary: don’t underutilize creative brain power
This principle is often referred to as the 8th lean waste and is fundamental to lean thinking 8. The
idea is that if all we expect from people is to perform their tasks without considering how
things could be improved, we are throwing the best part of people away, including the key to
our future success. Integral to Lean manufacturing is the concept that the production workers
are responsible for reducing Lean waste, not some distant manager or process engineer. The
people closest to the problem are expected to use their brains to improve the operating
environment. This is a far cry from the management attitude that employees are not “paid to
When you’re Agile you get Lean
It’s ironic that Lean emerged from manufacturing, the industry that championed the idea that
production is optimized by transforming people into assembly line automatons. What is doubly
ironic is when the outmoded notions for managing are applied to knowledge work such as
software development where people are paid to think! Yet this is precisely what happens when
software developers are expected to submit without reservation to overly prescriptive
methodologies and practices.
Corollary: the team is the unit of production
Software developers spend more time designing than they do building to specifications.
(building is done by the compiler). Design work requires experimentation with ideas. The book
“Where Good Ideas Come From 9” demonstrates how through time, innovation is enabled
through collaboration. Through collaboration, ideas born in the minds of individuals take root in
the real world and are nurtured until they bear fruit in the form of tangible business value.
In addition to providing a platform for the collaboration necessary to foster design-work, teams
can remove obstacles by swarming problems in hours that individuals working alone could
never resolve. Teams also are robust and self-healing in ways that are not possible for
For these reasons, Agile organizations measure productivity at the team level; not at the
individual level.
Agile practices
Small team size
The general guideline for an agile team size is about seven plus or minus 2 or about the size of a large
family. The team should be small enough to facilitate the development of strong interpersonal
Small teams reduce wait times and process waste because practitioners that know each other well
communicate efficiently and have fewer misunderstandings. Stronger relationships mean that people
are more likely and able to help each other remove obstacles, further reducing wait time and
processing (communication) waste. Better communication leads to more rapid task completion which
reduces WIP. Reduced misunderstanding also reduces the cause of some defects. The transport waste
of incomplete handoffs and translation errors are directly reduced through cohesive team
Persistent teams
When you’re Agile you get Lean
Teams take time to form. Over time their productivity and efficiency gets better and better. All of the
waste reduction advantages of small teams are strengthened as the team matures. The investment in
team development is lost if the team does not persist.
The retrospective is one of the team ceremonies in Scrum. The team spends time after each iteration
reflecting on what is working and what is not working and then makes a commitment to adjust their
behavior accordingly in some tangible way. It is a lightweight, self-directed process that teams use to
improve incrementally.
Typically the focus of retrospectives is to improve the team’s well-being, become more effective and
increase the quality of the outcome. Since retrospectives can improve all aspects of team
performance, all of the waste reduction advantages of small teams are strengthened through their use.
Cross-functional teams
Cross-functional teams possess all the functional capabilities needed to get work completed in
accordance with the Definition of Done. At a minimum this includes all the development skills that are
needed to develop and test the technologies that are integrated to form the product or system.
Additional functions that may be required on some teams are architecture, business analysis, usability,
user interface design, technical writing, content production and production operations.
Cross-functional teams reduce WIP, waiting, over-processing, translation and handoff waste by keeping
dependencies on functions outside of the team to a minimum and broadening the positive impact of
team collaboration. Defect waste is also reduced through better coordinated technology integration
and more tightly coupled development/test cycles.
Self-organizing teams
Self-organization is the organic process by which individuals interact and form into a team.
Organizations support this process by not unnecessarily interfering with this process (e.g., avoiding the
micro-management of task planning and assignment) and by providing an environment that facilitates
team development and sustainment. Self-organizing teams are encouraged to be as self-directed as
feasible, especially in regard to how work is defined, organized and implemented.
Self-organizing teams reduce the need for supervisor and project manager task management, which
reduces additional processing, waiting, translation and WIP waste. In addition, since self-organized
When you’re Agile you get Lean
teams have more control over how they do things, they are able to make deeper and more meaningful
commitments on what they can complete and how they will improve over time.
Collective code ownership
Collective code ownership is the principle that the team, not the individual, is responsible for all of the
work products that are produced.
This has a huge impact on reducing wait waste by avoiding single person bottlenecks. It also has a big
impact on defect reduction. Less time is wasted deciding who should be responsible (reducing motion
and over-processing) for fixing defects and more of the team’s collective time is allocated to
eliminating defects as a key objective. A commitment to collective code ownership is what makes it
possible for a team to commit to high standards for the Definition of Done and make commitments to
not “break the build” possible.
Single project assignment
Single project assignment (AKA dedicated teams) simply means that most, if not all, of the team
members are on one and only one project at a time.
Meaningful team commitments are impossible without full-time commitment of the team’s members,
since a singular focus is required to meet the short timescale commitments of iterative development
week after week. This means Agile cannot be practiced unless most team members are dedicated.
However, it can make sense for some team members to be involved part-time when their
contributions are required only occasionally (e.g. database administration).
Single assignment by definition reduces the waste of task-switching (transportation). There also is no
need to wait for team members to get back to work. WIP is reduced since the throughput of one
project is increased if it obtains the full capacity of the team members.
Co-location and facilitated team communication
Face-to-face co-location is the ideal for small team communications since it is by far the best way to
facilitate effective collaboration. Nevertheless distributed teams are a reality in today’s business
environment, which precludes this possibility. This barrier to collaboration can be remediated through
the use of other means to facilitate high-bandwidth intra-team communication.
This includes all the efforts needed to assure that distributed team members are able to effectively
communicate and collaborate. This takes into account travel, video, social media, collaboration tools,
co-locating when you can, and the like.
When you’re Agile you get Lean
Without a solid investment in and on-going commitment to facilitated communication, you will not be
able to develop or sustain an effective Agile team. As team communication improves and grows more
continuous, wait times are reduced and overall understanding improves between team members. This
reduces the incidence of misunderstandings, which means fewer defects. In addition, the need to
translate (transportation) is reduced as well as the motion needed to work together.
Pair programming is when two programmers work at one workstation together to produce unit tests
and source code. As counter-intuitive as it may seem, pair programming is usually more efficient and
results in higher quality outcomes than the alternative.
Continuous code reviews
One way pair programming reduces wait time is through the practice of continuous code review (one
person reviews the code while the other person is writing it). As can be seen in the diagram above,
continuous code reviews reduce wait and handoffs states by collapsing a two-step process into one
and reduce extra processing by reducing re-work. When all team members over time pair with each
other, relationships are strengthened and cross-fertilization of skills and knowledge result which
decreases wait waste by eliminating single person dependencies and increases the teams collective
ability to produce higher quality outcomes, which reduces defects.
The following table summarizes our discussion of how the Agile practices implement Lean concepts of
When you’re Agile you get Lean
waste reduction. Although we have discussed the practices individually, they are designed to work
together as part of an Agile system of thinking drawn from Scrum, Extreme Programming and Lean.
When you’re Agile you get Lean
When you’re Agile you get Lean
So when we add up all the different ways we can reduce waste through the use of Agile practices, how
much does it amount to? The answer is a lot. Practices such as early and frequent delivery and
iterative development can have an immediate and dramatic impact on reducing waste such as WIP,
which can easily be measured in financial terms such as increased return on investment, lower
development costs and reduced write-off risk. Shaving waste consistently over time has revolutionized
manufacturing across the world; now it’s revolutionizing software development. Lean started out as a
competitive advantage for Toyota. Today if you expect to be a player in the manufacturing industry it is
a competitive reality. We have every reason to believe that what has been a competitive advantage in
software development will soon become a capability that is necessary to compete.
When you’re Agile you get Lean
Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press,
Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press,
Shingo, Shigeo. A Study of the Toyota Production System. China: Productivity Press, 1989.
Manifesto for Agile Software Development, http://agilemanifesto.org/, 2001
Boehm, Barry. Software Engineering Economics. New Jersey: Prentice Hall, 1981
Martin Fowler, Continuous Integration, http://martinfowler.com/articles/continuousIntegration.html,
May 01, 2006
Poppendieck, Mary and Tom. Lean Software Development: An Agile Toolkit. Boston: Addison-Wesley
Professional, 2003.
Pete Abilla, The 8th Type of Muda, http://www.shmula.com/the-8th-type-of-muda/309/, January 23,
Johnson, Steven. Where Good Ideas Come From. New York: Riverhead Trade, 2011