When you’re Agileyou get Lean

When you’re Agile you get Lean

1

Introduction Lean manufacturing (or simply “Lean”) refers to the manufacturing philosophy laid out in the Toyota Production System1. 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 quality. 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 end-customer. 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 Ohno2, 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.

1. 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

2

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

2. 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.

3. 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.

4. 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, over-production increases the risk of obsolescence.

When you’re Agile you get Lean

3

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 pre-maturely.

5. 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 worse.

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.

6. 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 transportation.

Requirements “Lost in translation”

When you’re Agile you get Lean

4

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 much. 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 rule-driven. 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.

When you’re Agile you get Lean

5

1. Deploy as soon as possible 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 fix5. 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 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 cause.

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).

The cost of deferring a defect5

When you’re Agile you get Lean

6

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 end-user feedback, which reduces defect waste. Defect waste is also reduced by shortening the times between defect origination, defect discovery and defect fix. 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!

Short release cycles reduce WIP

When you’re Agile you get Lean

7

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

Short iterations reduce WIP

When you’re Agile you get Lean

8

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 over-production. 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 repository6. 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

9

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

10

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 damage7. 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 cycle.

When you’re Agile you get Lean

11

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

Dynamic backlog management

When you’re Agile you get Lean

12

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

13

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 thinking8. 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 think.”

When you’re Agile you get Lean

14

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 From9” 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 individuals. 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 relationships. 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 relationships.

When you’re Agile you get Lean

15

Persistent teams 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. Retrospectives 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

16

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

17

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 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.

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.

Summary The following table summarizes our discussion of how the Agile practices implement Lean concepts of

Continuous code reviews

When you’re Agile you get Lean

18

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

19

When you’re Agile you get Lean

20

Conclusion 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

21

Endnotes 1 Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press, 1988 2 Ohno, Taiichi. Toyota Production System: Beyond Large-Scale Production. China: Productivity Press, 1988

3 Shingo, Shigeo. A Study of the Toyota Production System. China: Productivity Press, 1989.

4 Manifesto for Agile Software Development, http://agilemanifesto.org/, 2001 5 Boehm, Barry. Software Engineering Economics. New Jersey: Prentice Hall, 1981

6 Martin Fowler, Continuous Integration, http://martinfowler.com/articles/continuousIntegration.html, May 01, 2006 7 Poppendieck, Mary and Tom. Lean Software Development: An Agile Toolkit. Boston: Addison-Wesley Professional, 2003. 8 Pete Abilla, The 8th Type of Muda, http://www.shmula.com/the-8th-type-of-muda/309/, January 23, 2007

9 Johnson, Steven. Where Good Ideas Come From. New York: Riverhead Trade, 2011