SolutionsIQ When You’re Agile, You Get Lean · 2018-03-23 · SolutionsIQ When You’re Agile, You Get Lean By Charlie Rudd Introduction Lean manufacturing (or simply “Lean”)

SolutionsIQ

When You’re Agile, You Get Lean

By Charlie Rudd

IntroductionLean manufacturing (or simply “Lean”) refers to the manufacturing philosophy laid out in the Toyota Production System. By applying this philosophy systematically to the manufacture of cars, Toyota became the global leader with a brand 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 customer value of the final product.

Taiicho Ohno first described the seven Lean wastes in his book Toyota Production System: Beyond Large-Scale Production.1 Although it differs from manufacturing in important ways, software development has analogous wastes. Once you start looking for them, they are surprisingly easy to find.

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 briefly describe the seven different kinds of manufacturing waste and discuss their analogs in software development. Then we will introduce guiding principles that the Lean and Agile philosophies share and discuss some of their implications. Finally we will discuss the Agile practices that embody these principles and demonstrate how they reduce software development waste.

SAFE AND BEYOND - A SUCCESS STORY

2


facebook twitter soundcloud youtube linkedin@SOLUT IONS IQ

1. Inventory

The Seven Lean Wastes

Waterfall software project WIP

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. The longer last year’s model sits in the warehouse, the more likely it will never be sold. Similarly, the more work in process, the greater the risk that some portion of that work will never result in a finished product and a sale.

Inventory in Software DevelopmentIn 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 of write-off risk for software investments because if the project ends prematurely or never is released, no business value will be generated and the WIP investment will be lost.


3



2. MotionMotion 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) that gave rise to Lean manufacturing, it’s only the last turn of a bolt that tightens it—the rest is just movement.2

Motion in Software developmentMotion in team members is manifested through activities like travel time, walking to meetings, task-switching between projects and work interruptions. A 10-second work interruption can result in a five-minute think-time reset for a developer. In knowledge work, each time you switch thinking tasks, you disrupt the flow of your thoughts and waste brain power and the WIP investment will be lost.

3. WaitingWaiting is the delay between steps in production. If an order comes in the mail and sits in a mailbox, the time spent in the mailbox is the waste of waiting. If an item is assembled, the delay before it is packaged is the waste of waiting.

Waiting in Software developmentExamples 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, etc. Any elapsed time in excess of what is needed to execute the added value step is a form of waiting. When you start looking for it, waiting is easy to find, even in what at first appeared to be the most efficient of operations, leaving plenty of opportunity for future improvements.

4. TransportTransportation 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 result from transportation.

Transport in Software developmentSince software comprises information electronically stored and accessed, the physical transport of materials or finished

Requirements “lost in transportation”


4



goods is of little concern. However, there is the analogous waste of translating and handing-off customer requirements through subsequent project phases such as functional specifications, UML diagrams, source code and tests. Information loss or the introduction of noise can also be damaging just as finished goods and materials are sometimes damaged through transportation.

5. Over-ProductionOver-production is production ahead of demand. For example, saleable units waiting in warehouses for buyers are over-production waste. As is the case with inventory and WIP, over-production increases the risk of obsolescence.

Over-Production in Software DevelopmentSince 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 (2) deployed prematurely. At The 2002 XP Conference, Jim Johnson from the Standish Group shared the results of their research of redundant features and functions (see inset).3

6. Over-ProcessingOver-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

Rarely or never used features compared to all features released


5



emotional distress of waiting by fostering the illusion that at least something “productive” is getting done, but if it’s not adding value in the eyes of the customer, then it’s making things worse.

Over-Processing in Software DevelopmentOver- processing 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, as well as 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.

7. DefectsThe waste of defects refers to the cost of searching for and fixing defects as well as downstream damage caused by defects.

Defects in Software DevelopmentDefects or bugs and the effort and cost of software testing are well known. However the testing and inspections that do not result in finding bugs are also 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.

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 value in the eyes of the customer, then it’s making things worse.


6



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 mindset 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 mindset and philosophy. After each principle we will provide examples of Agile practices that embody that principle and demonstrate how they reduce software development waste.

Principles and Practices: Methodology or Mindset?

When practitioners adopt Agile practices, they are expected to think more not less.


7



1. Deploy as Soon as PossibleIn essence 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, it’s 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 of defects and fixing them as soon as possible—is core to both Agile and Lean. 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.

True cost of a bug fix


8



Agile PracticesEarly and Frequent DeliveryEarly 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 minimum marketable features (MMF).

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 DoneIf 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 what is called a definition of done (DOD). At a minimum, the DOD 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 definition 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 Agile software project WIP


9



DOD to its logical conclusion by implementing “continuous delivery” and deploy code to production after each iteration. In some cases, code may be pushed to production one or more times each day!

By completing everything that needs to be done for a small slice of work, WIP is dramatically decreased. 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 the Product Owner. The ScrumMaster is devoted to removing obstacles that cause delays to production. Meanwhile, the Product Owner is devoted to providing answers about requirements in a timely manner. Also, the daily Scrum (standup) meeting provides an opportunity for all team members to update the team on their progress, which makes obstacles 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 out 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 CoverageThe 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, procedure or validation). The ability to easily automate tests while code is being written makes it much

Agile and Waterfall WIP compared


10



more feasible to achieve the commitment to comprehensively test all source code within the iteration.

Further benefits of test automation:

» Less waiting for test results

» No need to defer testing to the future, which reduces WIP.

» Reduced wait time because automated testing is part of frequent automated regression testing

» Reduced manual testing, which in turn reduces physical motion

» Reduced need for future debugging because testing is comprehensive and motion of coding is reduced

» Reduced chance of defects: the more comprehensive and earlier the testing, the smaller the likelihood that bugs will make their way into production

» Fewer errors generated from handing code back and forth between developers and testers

Meanwhile, a high percentage of unit test coverage reduces over-processing by reducing the need and likelihood of redundant acceptance testing.

Test-Driven DevelopmentIn 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.

Much like 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 below), 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 over-processing and over-production waste. 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,


11



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. User acceptance tests, performance tests, and code analytics can also 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 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 may have been written by a different team member. Typically, this means another Agile practice—collective code ownership (discussed below)—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) ReviewAn iteration, or Sprint as it is called in Scrum, is the period of time during which the team works on the unit of value they expect to deliver at the end of this period. High-performing teams often employ an iteration review (or Sprint Review) to share the outcomes of the iteration with stakeholders. This review process is in effect a mini user acceptance


12



test. Business representatives see the new code in action and can evaluate whether the implementation provides the value behind the requirements. These demonstrations help business representatives provide useful feedback for the next step in the project. Iteration review adds another 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 does the business need to wait on the team to get a tangible idea of progress. Defects are reduced via the practical measure of user validation and acceptance.

2. Defer Decisions to the Last Responsible MomentAt first blush, this practice 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. In Agile, you 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

Agile PracticesJust-In-Time Requirements and a Dynamic Product BacklogJust-in-time requirements is the practice of deferring the full elaboration of the requirement until just before

Corollary > Do just enough and no more.

Agile teams apply this practice to all 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 avoiding 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.


13



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 can be added or deleted at any time by the business representative (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.

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. 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 mental effort 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.Dynamic backlog management


14



Multi-Level PlanningMulti-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, which 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 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 detailed planning of work is done during not prior to the production process and favors discussion, collaboration and implementing over maintaining written documentation.

Since task-level planning is limited to imminent work, plan inventories and WIP is kept to a minimum. As a result, 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 dynamic backlogs. 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 CollaborationBusiness collaboration is the commitment of the development team and the business representatives to work together on a continuous basis. This continuous engagement over the course of the project is a departure from the traditional project approach where business contact is concentrated at the beginning and end. In many organizations, this can mean that the business

Dynamic backlog management


15



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 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 paired with iterative 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 PowerLeveraging 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

Corollary > Don’t underutilize creative brain power.

This principle is often referred to as the 8th Lean waste and is fundamental to Lean thinking. 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.”

It’s ironic that Lean—the champion of worker empowerment—emerged from manufacturing, the industry that originated the idea that production is optimized by transforming people into assembly line automatons. What is doubly ironic is when these 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 policies.


16



must make deep, lasting 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.

Agile PracticesSmall Team SizeThe general guideline for an Agile team size is about seven plus or minus two, 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 more able to help each other remove obstacles, further reducing wait time and over-processing 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.

Persistent TeamsTeams 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. This is often the case when the business decides to break the team members up and redistribute them, whether to

Corollary > The team is the unit of production.

Software developers spend much more time designing than they do building to specifications. Design work requires experimentation with ideas. The book “Where Good Ideas Come From” demonstrates how over time, collaboration enables innovation.8 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 to fix in hours problems that individuals working alone might never be able to resolve. Teams also are robust and self-healing in ways that individuals simply are not.

For these reasons, Agile organizations measure productivity at the team level, not at the individual level.


17



other teams or—worse—to non-Agile projects.

RetrospectivesThe 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 outcomes. 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 TeamsCross-functional teams possess all the functional capabilities needed to get work completed in accordance with the Definition of Done (see above). 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 for release. 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 TeamsSelf-organization is the organic process by which individuals interact and form into a team. Organizations can support this process by not interfering unnecessarily 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 teams have more control over how they do things, and they are able to make deeper and more meaningful commitments on what they can complete and how they will improve over time.

Collective Code OwnershipCollective code ownership is the principle that the team, not the individual, is responsible for all of the work products that are produced.


18



This has a huge impact on reducing wait waste by avoiding single-person bottlenecks. It also has a big impact on defect reduction. Moreover, the team spends less time deciding who should be responsible for fixing defects (in the process also reducing motion and over-processing) and more collective time eliminating defects as a shared 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 AssignmentSingle-project assignment (also known as “dedicated teams”) simply means that most, if not all, team members are on one and only one project at a time. Meaningful team commitments—and thus many of the benefits of adopting Agile—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. However, it can make sense for some team members to be involved part-time if 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 CommunicationFace-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 the imperative that all teams be co-located. This barrier to collaboration can be eased through the use of high-bandwidth intra-team communication, including: travel, video conferencing, social media, collaboration tools, collocating when you can, as well as all other efforts needed to assure that distributed team members are able to effectively communicate and collaborate.

Without a solid investment in and an 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.


19



Pair ProgrammingPair 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 where one person reviews the code while the other person is writing it. As can be seen in the diagram below, continuous code reviews reduce wait states and handoffs by collapsing a two-step process into one step and reduce extra processing by reducing re-work.

When all team members over time pair with each other, relationships are strengthened and cross-pollination of skills and knowledge result, further decreasing wait waste by eliminating single person dependencies and increasing the team’s collective ability to produce higher-quality outcomes.


20



ConclusionThe following table summarizes our discussion on how Agile practices implement Lean concepts of waste reduction.


21



All the waste reduction opportunities discussed in this paper, plus many more, are available to any organization that implements Scrum and Extreme Programming. Some of the practices, such as early and frequent delivery and iterative development, can have an immediate and dramatic impact that can easily be measured in financial terms such as increased return on investment, lower development costs and reduced write-off risk.9 Others have an incremental effect that continues to generate new value year after year.

The Lean waste reduction mindset and philosophy transformed manufacturing. Today, the Lean-inspired Agile movement is transforming the world of software development. Lean started as a competitive advantage that propelled Toyota to global leadership. In manufacturing today, no matter where you are in the world, if you don’t do Lean you can’t compete. We have every reason to believe it will also be the case for the software industry that, if you don’t do Agile, you won’t be able to compete.

1 Toyota Production System: Beyond Large-Scale Production. Ohno, Taiichi. 1988

2 A Study of the Toyota Production System. Shingo, Shigeo. 1989

3 http://www.martinfowler.com/articles/xp2002.html. Fowler, Martin. 2002

4 Manifesto for Agile Software Development. 2001

5 Software Engineering Economics. Boehm, Barry. 1981

6 Continuous Integration. Fowler, Martin. 2006

7 Lean Software Development: An Agile Toolkit. Poppendieck, Mary and Tom. 2003

8 Where Good Ideas Come From. Johnson, Steven. 2011

9 The Business Value of Agile Transformation. Rudd, John. 2015


22


facebook twitter soundcloud youtube linkedin@SOLUT IONS IQ 22

Want to learn more?Visit SolutionsIQ.com

Email: [email protected]

Toll-Free: 1-800-235-4091

Direct: 1-425-451-2727

SolutionsIQ

When You’re Agile,You Get Lean

Documents

SolutionsIQ When You’re Agile, You Get Lean · 2018-03-23 · SolutionsIQ When You’re Agile, You Get Lean By Charlie Rudd Introduction Lean manufacturing (or simply “Lean”)