What is *Lean Software Development* by Mary Poppendieck about?

*Lean Software Development* adapts Toyota’s Lean manufacturing principles to software engineering, focusing on eliminating waste, delivering customer value faster, and fostering continuous improvement. It outlines seven core principles, including amplifying feedback, delaying commitment, and empowering teams, to optimize workflows and create high-quality software. The book blends case studies, exercises, and actionable strategies for streamlining development processes.

Who should read *Lean Software Development*?

This book is ideal for software developers, project managers, and IT leaders seeking to reduce inefficiencies and enhance product quality. It’s also valuable for Agile practitioners looking to integrate Lean thinking into iterative workflows, as well as anyone interested in customer-centric, waste-free development methodologies.

Is *Lean Software Development* worth reading in 2025?

Yes. Despite being published in 2003, its principles on waste reduction, rapid feedback, and systems thinking remain foundational in modern DevOps and Agile practices. The focus on adaptability and customer value aligns with current trends like CI/CD and MVP-driven development, making it a timeless resource.

What are the 7 core principles of Lean Software Development?

1. **Eliminate waste** (non-value-adding activities). 2. **Amplify learning** through iterative feedback. 3. **Decide as late as possible** to retain flexibility. 4. **Deliver as fast as possible** to accelerate learning. 5. **Empower teams** to make decisions. 6. **Build integrity in** via continuous testing. 7. **Optimize the whole system**, not individual parts.

How does Lean Software Development reduce costs?

By cutting waste (e.g., unused features, delays), minimizing rework through early feedback, and simplifying code to lower maintenance costs. Lean’s focus on incremental delivery prevents overinvestment in unvalidated ideas, ensuring resources align with actual customer needs.

What role does customer feedback play in Lean Software Development?

Customer feedback loops are central. Teams release minimal viable products (MVPs) early, gather user insights, and iterate rapidly. This ensures alignment with market demands, reduces the risk of building unnecessary features, and builds trust through responsive development.

How does *Lean Software Development* differ from Agile methodologies?

While both emphasize iterative delivery, Lean prioritizes **waste reduction** and **end-to-end value streams**, whereas Agile focuses on collaboration and adaptability. Lean introduces manufacturing-inspired concepts like *just-in-time decision-making*, whereas Agile frameworks (e.g., Scrum) structure workflows via sprints and roles.

What real-world examples illustrate Lean Software Development?

The book cites cases where teams: - Shortened release cycles from months to weeks by eliminating bureaucratic approvals. - Reduced bug-fixing costs by 60% through automated testing. - Improved customer satisfaction by involving users in prioritization workshops.

린 소프트웨어 개발의 적용

개념에서 현금화까지

메리 포펜딕

4.18(1065 Reviews)

린 소프트웨어 개발의 적용 개요

2003년부터 소프트웨어 개발의 혁신을 일으킨 "린 소프트웨어 개발(Lean Software Development)"은 거대 기술 기업들이 제품을 만드는 방식을 변화시켰습니다. 포펜딕(Poppendieck) 부부의 낭비 제거 원칙은 업계 전반에 걸쳐 폭포수 모델에서 애자일로의 전환을 촉발했습니다. 왜 이 방법론은 전 세계 소프트웨어 리더들의 필독서가 되었을까요?

전달 방식을 선택하세요

한 권의 책, 다양한 듣기 방식.

린 소프트웨어 개발의 적용의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Ever wonder why some software projects deliver elegant, user-friendly systems while others become bloated, buggy nightmares? The answer might come from an unexpected source: automobile manufacturing. When Mary Poppendieck returned to software development after years in manufacturing leadership at 3M, she was shocked to find the industry dominated by heavy process definition and detailed front-end planning-approaches that contradicted everything she'd learned about lean manufacturing. This revelation led her and her husband Tom to write "Lean Software Development: An Agile Toolkit," a groundbreaking work that has influenced countless development teams since its publication. The book has become required reading in many technology companies, with executives at firms like Spotify and Netflix citing its principles as foundational to their development approaches. Even tech giants like Google and Microsoft have incorporated these lean principles into their development practices, demonstrating the book's enduring relevance in an ever-changing technology landscape.

2장

Eliminate Waste: The Foundation of Lean Thinking

Imagine spending months meticulously documenting requirements for software that, once built, doesn't actually solve the customer's problem. This scenario represents one of the most fundamental forms of waste in software development-effort that creates no value. The concept of eliminating waste originated with Toyota's Taiichi Ohno in the late 1940s when he faced the challenge of manufacturing affordable cars in small quantities for the Japanese market. Ohno defined waste broadly as anything not directly creating customer value. In software development, this translates to seven specific types of waste: partially done work, extra processes, extra features, task switching, waiting, motion, and defects. Partially done work is particularly insidious-unintegrated code sitting in development represents investment without return and carries the risk of becoming obsolete before delivery. Documentation that no one eagerly awaits represents extra process waste. "Just in case" features create code that must be maintained but may never be used. Task switching between multiple projects creates significant overhead-studies show that developers lose productivity every time they change context, making two sequential two-week projects faster to complete than two projects done in parallel over four weeks. Waiting-for approvals, testing, or deployment-prevents customers from realizing value and reduces an organization's ability to respond to market needs. Motion waste occurs when developers must seek answers from distant experts rather than having them nearby. And defects create waste proportional to their severity multiplied by detection time-a critical defect found immediately creates minimal waste, while a minor defect undiscovered for weeks creates much more. To combat these wastes, lean practitioners use value stream mapping-a technique that visualizes the flow from customer request to delivery, revealing where value is added and where waste occurs. By physically following a customer request through your organization and measuring time spent in each step, you can identify bottlenecks and streamline processes. Traditional value streams often show that only a small percentage of time is spent on value-adding activities, with the rest consumed by waiting and handoffs. One organization transformed their development process from a year-long cycle with only 33% value-adding time to a three-month process with most time spent adding value. Key improvements included weekly approval meetings, dedicated staffing, incremental development, and early deployment planning-all focused on rapid customer response. The journey to eliminating waste begins with learning to see it. As you examine your development process, ask whether each activity directly contributes to customer value. If not, it's a candidate for elimination or streamlining. Remember, waste isn't just inefficiency-it's anything that doesn't directly contribute to solving the customer's problem.

들리는 모든 단어를 눈으로 확인하세요

린 소프트웨어 개발의 적용의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

Amplify Learning: Software Development as Knowledge Creation

Software development isn't a production process-it's fundamentally about learning. While manufacturing focuses on following established recipes with minimal variation, development creates the recipe through exploration and discovery. This distinction is crucial because applying production-oriented practices to development often leads to failure. Quality in software requires both perceived integrity (delighting customers through balanced functionality) and conceptual integrity (a cohesive system design). Unlike manufacturing, which defines quality as conformance to requirements, software quality means fitness for use-even as problems and needs evolve. Research by Raymonde Guindon challenges the notion that good programmers work in a structured, top-down manner. When tackling ill-defined problems, experienced designers move fluidly between examining scenarios, clarifying requirements, high-level solution development, and detailed design of difficult elements. This unstructured approach is necessary for understanding complex problems. Problem-solving requires generating information through experimentation. In software, two schools exist: making everything perfect the first time versus rapid try-it, test-it, fix-it cycles. For ill-structured problems, the latter typically works better. As Edward Yourdon noted, programming logic often needs multiple revisions to achieve elegance, just like professional writing requires multiple drafts. Feedback transforms systems from rigid to responsive. Even Winston Royce, whose work became associated with the waterfall model, recognized in 1970 that early feedback through prototyping was essential. When software projects struggle, increasing feedback-not imposing more rigid sequential processes-is typically the most effective solution. Iterations are as fundamental to lean development as small batches are to lean manufacturing. An iteration is a useful increment of software designed, programmed, tested, integrated, and delivered during a short, fixed timeframe. Unlike sequential development, iterations provide dramatic increases in feedback between customers and developers, expose design problems early, and build change-tolerance into the system. Effective iteration planning focuses on implementing coherent feature sets that deliver meaningful business value but are small enough to complete within a single iteration. Features come from customers as use cases, stories, or backlog items. At the beginning of each iteration, the development team estimates the difficulty level of features while customers decide which are most important given their cost. A key strategy for achieving convergence is working on top-priority items first, letting low-priority items fall off the list. Since studies show 45% of features in typical systems are never used and 19% rarely used, negotiable scope makes sense. By delivering highest-priority features first and measuring team velocity, projects become more predictable, not less. Set-based development offers an alternative to traditional point-based approaches by working with multiple options simultaneously and gradually narrowing possibilities. Rather than committing to a single solution early, set-based development encourages creating multiple alternative solutions to difficult problems. While seemingly wasteful, this approach often leads to better solutions faster. When tackling difficult problems, resist jumping to solutions and instead keep constraints visible so the team can discover design intersections that work for all concerned. Through repeated meetings where unworkable ideas are eliminated, novel solutions often emerge that no one would have conceived initially.

4장

Decide as Late as Possible: Maintaining Options in an Uncertain World

In the 1980s, U.S. automakers waited for "frozen" designs before cutting dies for new car bodies, resulting in costly changes when designs inevitably shifted. Japanese manufacturers, however, used concurrent development-starting die production simultaneously with car design. Die engineers anticipated solutions, maintained constant communication with body engineers, and used techniques allowing late changes. This approach reduced change costs significantly and produced better dies. Similarly, sequential software development forces depth-first approaches that lead to costly mistakes by committing to detailed decisions too early without understanding high-level consequences. Concurrent software development, typically through iterative approaches, allows breadth-first exploration that discovers major problems early. Starting programming after high-level conceptual design, even while detailed requirements are still evolving, provides insurance against costly mistakes. Options thinking applies the concept of "satisfaction guaranteed" to software development. HP discovered that delaying printer electrical configuration until warehouse delivery saved $3 million monthly despite higher unit costs, by perfectly matching supply to demand. Economist Enrico Zaninotto explained that just-in-time systems control complexity by minimizing irreversible actions, contrasting with mass production's approach of limiting options. Microsoft demonstrated perfect options thinking at the 1988 Comdex trade show with their seemingly confused strategy-simultaneously offering DOS, early Windows, OS/2, UNIX, and applications for multiple platforms. While competitors committed to single platforms, Gates hedged his bets across operating systems. By developing expertise in both operating systems and applications while letting the market determine winners, Gates kept choices open until uncertainty resolved. The debate between predictive and adaptive processes centers on when decisions should be made. Predictive approaches specify requirements and design upfront, assuming a stable world. Adaptive approaches create options that delay decisions until customer needs are clearer and technologies mature. Agile development isn't unplanned-plans enhance flexibility-but avoids prespecifying detailed actions based on speculation. Concurrent development means delaying commitment until the "last responsible moment"-the point where not deciding eliminates important alternatives. This isn't procrastination but requires disciplined tactics: sharing partial design information, enabling direct worker collaboration, and developing change absorption capabilities. Expert developers know how to delay commitments and repair errors before they cause problems, unlike amateurs who overcommit early. Problem-solving strategies come in two forms: breadth-first (like a funnel) and depth-first (like a tunnel). Depth-first approaches make early commitments and quickly reduce complexity, making them attractive to novice designers. However, they risk narrowing focus too soon and incur high change costs if redirection becomes necessary. Breadth-first approaches delay commitments and work better when business domains are evolving. Gary Klein's research on emergency responders revealed that experienced professionals rarely make conscious decisions-they simply know what to do based on pattern recognition and mental simulation. This intuitive decision-making approach, built on experience and situational training, proves highly successful. Rational, deliberative decision-making is actually the fallback approach used only when experience is inadequate. The U.S. Marines specialize in chaos, with everything geared toward high-speed, complex environments. Their approach includes rapid but thorough planning focused on understanding situations rather than predicting outcomes. Once engaged, organizational structure collapses, with frontline personnel making decisions based on current information. Leaders communicate clear intent while leaving details to those on the ground.

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

5장

Deliver as Fast as Possible: Speed as Competitive Advantage

Companies like Federal Express, L.L.Bean, and LensCrafters transformed their industries through rapid delivery capabilities. Rapid delivery benefits both customers and businesses. Customers gain increased flexibility, the ability to delay decisions, and quicker gratification. Businesses reduce risk by delivering before customers change their minds, minimizing work-in-process inventory that might become obsolete, and uncovering problems sooner. Rapid delivery requires everyone to know what they should be working on at all times. In fast-moving environments, central command structures are too slow; instead, local signaling and commitment mechanisms must coordinate work by letting customer needs pull the work rather than schedules pushing it. MRP (material requirements planning) systems failed when used for shop floor scheduling because they were "nervous"-the slightest change would completely reorganize the entire schedule. Just-in-time manufacturing solved this through pull systems using kanban, where work is triggered by downstream customer needs. When parts are used, kanban cards signal upstream workstations to produce replacements. Software pull systems start with short iterations based on customer input. Features are written on index cards (like kanban cards) which developers choose from a "To Do" area, move to "Checked Out" while working, and finally to "Tests Passed" when complete. Daily 15-minute team meetings help coordinate work, with each member sharing yesterday's accomplishments, today's plans, and where help is needed. Information radiators are visual controls that make work self-directing by showing what's happening, what needs doing, and what problems exist. These include kanban boards showing work status, burn-down charts tracking progress, and visible lists of problems, improvement ideas, and refactoring candidates. Bottlenecks in development can be addressed through queuing theory, which focuses on reducing cycle time (the total time from entering a process to completion). Queuing theory shows that: 1) Work-in-queue directly correlates to cycle time; 2) Variability increases cycle time; 3) Larger batch sizes increase cycle time; 4) Higher utilization increases cycle time non-linearly; 5) With high variability, even moderate utilization causes delays. Resources at full utilization dramatically increase cycle time. When managers try to keep testers or developers 100% busy, they create growing backlogs and longer delays. Small batches move through systems much faster than large ones, especially at high utilization. Unlike computer servers that are never run at full capacity, software teams are often overloaded, creating bottlenecks that harm the entire value stream. Traditional cost analysis often fails to account for the value of delivering software faster. By creating economic models that show the impact of delay on profitability, teams can make better decisions about investments in tools and process improvements. The cost of delay is frequently the highest leverage point in product development economics, with delays causing significant market share and revenue losses that far outweigh development cost overruns.

6장

Empower the Team: Unleashing Human Potential

The NUMMI case study demonstrates the power of self-determination. When Toyota took over GM's failed Freemont plant in 1984, they rehired the same workers but transformed the culture by having teams design their own work procedures. Within two years, productivity doubled, quality soared, and worker satisfaction dramatically improved. The key difference: rather than engineers dictating procedures, workers used stopwatches to design their own jobs, with management serving as coaches and trainers. Most organizational improvement programs fail because they impose change from above. GE's Work-Out program succeeded by inverting this model-workers propose improvements while managers must make immediate yes-no decisions on their ideas. The program empowers those closest to the work to identify process barriers and implement solutions, with management's role shifting to enabling rather than directing. 3M's remarkable innovation success stems from William McKnight's organizational design that nurtures self-organizing teams. For over 75 years, the company has maintained its competitive edge through a simple formula: scientists spend 15% of their time on projects of their choosing, product champions recruit volunteer teams around compelling ideas, and managers serve as sponsors who protect these initiatives. Intrinsic motivation requires four essential building blocks: belonging, safety, competence, and progress. Belonging emerges when teams have clear shared goals and win or lose together, without individual competition. Safety requires an environment where mistakes are tolerated as part of learning and growth, avoiding what the U.S. Army calls a "zero defects mentality" that kills initiative. People need to believe they're capable of doing good work and be part of something successful. Software development requires discipline-version control, coding standards, build processes, and automated testing-for work to proceed smoothly. Competence comes from knowledge, skill, positive feedback, high standards, and meeting difficult challenges. Even highly motivated teams need to feel they've accomplished something, which reaffirms purpose and keeps everyone energized. This is a compelling reason for iterative development-teams regularly put their work in front of customers and get feedback. Projects need meaningful, visible measurements showing progress toward goals. Leadership differs fundamentally from management-as John Kotter notes, "No one has yet figured out how to manage people effectively into battle; they must be led." At 3M, every major new product development is led by a "champion" who writes the initial concept, gathers management support, recruits the team, and interprets the product vision. Similarly, Toyota's chief engineers study target markets, establish designs, set schedules, and take complete responsibility for vehicle performance. Research by Bill Curtis found that large systems typically have a single or small team of "exceptional designers" who assume primary design responsibility. These master developers lead through superior knowledge rather than formal authority. They deeply understand both customers and technical issues, are consumed with their systems' success, and become communication focal points.

들리는 모든 단어를 눈으로 확인하세요

린 소프트웨어 개발의 적용의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

Build Integrity In: Creating Cohesive Systems That Delight Users

In the late 1980s, Harvard's Kim Clark found that the key differentiator between average and high-performing companies was product integrity, which has two dimensions: perceived integrity and conceptual integrity. Perceived integrity means the product achieves a balance of function, usability, reliability, and economy that delights customers. Conceptual integrity means the system's central concepts work together as a smooth, cohesive whole. Perceived integrity is in the eyes of the beholder-it's when software suits users so well they feel the designer must have been "inside their head." Google exemplifies this with its speed, clean results display, and forgiving nature with typos. Conceptual integrity means a system's components match and work well together, with the architecture balancing flexibility, maintainability, efficiency, and responsiveness. According to Clark and Fujimoto, integrity is achieved through excellent information flow. Perceived integrity reflects the quality of information flow from customers to developers, while conceptual integrity reflects the upstream/downstream technical information flow within the development team. Perceived integrity requires direct communication between customers and developers. Traditional sequential development fails because customer requirements pass through multiple layers of documentation and handoffs, losing critical information. Instead, companies that achieve perceived integrity keep customer values directly in front of technical decision-makers. Model-driven design creates a domain model that both customers and developers understand and use directly. Eric Evans advocates using a "ubiquitous language" where everyone uses the same terminology, typically drawn from the customer domain. Effective models include conceptual domain models capturing key entities and relationships, glossaries defining consistent terminology, use case models showing dynamic system behavior, and qualifiers describing performance requirements. Software architecture typically begins with standard architectural layers that provide a solid foundation. The basic layers include presentation (user interface), domain (business logic), and data source (persistence, messaging). Lower layers shouldn't depend on higher ones, allowing each layer to be tested independently. This layering creates high cohesion within layers and separation of concerns between them-fundamental architectural patterns that achieve system integrity. Engineering historian Henry Petroski shows that design improvement comes from starting with something that works, learning from its weaknesses, and making improvements. Complex systems have effects not fully understood at design time, making suboptimal choices inevitable. This contradicts fears that iterative development produces ineffective architecture. Like lean manufacturing's continuous improvement philosophy, software systems require ongoing refinement by developers. Testing in software development serves similar purposes as in manufacturing: ensuring each component works correctly and the whole system functions as intended. Tests play five crucial roles: they communicate how things should work, provide feedback on whether the system works correctly, create scaffolding for safe changes throughout development, document how the system was actually built, and enable safe maintenance of production systems.

8장

See the Whole: Systems Thinking in Software Development

Systems thinking examines organizations as interconnected systems where the whole is more than the sum of its parts. The best system depends not on individual component performance but on how well parts work together. When analyzing organizations through system dynamics, computer simulations often reveal unintended consequences of seemingly sound policies. Like Lance Armstrong winning the Tour de France while winning few individual stages, optimizing every component of a system often produces poor overall results. Breaking large jobs into smaller tasks creates a temptation to optimize each task separately, but this rarely maximizes system performance. When measurements focus on local optimization, they can harm system-wide performance. For example, a testing department measured on "applied ratio" (percentage of available hours charged to other departments) keeps staff numbers low and maintains large backlogs to ensure high utilization. This forces customer departments to wait longer for testing, increasing cycle times, reducing feedback, and ultimately producing lower quality products with more defects-which ironically increases the testing workload further. DeMarco and Lister warn that measuring knowledge worker performance "courts dysfunction." Rob Austin's theory explains why: people optimize whatever metrics are used to evaluate them. Since it's impossible to measure everything important in knowledge work-especially with unique efforts under uncertainty-partial measurements inevitably lead to suboptimized behavior. The solution isn't more granular measurement but more aggregated measurement-moving up a level rather than down. Like Nucor measuring group productivity instead of individual performance, or 3M measuring business profitability rather than development costs. The sharp division between firms presents a significant barrier to agile development. Traditional wisdom suggests airtight contracts are the only protection when working across company boundaries, but Toyota pioneered a better approach. By 1998, suppliers rated Toyota as the most trusted automaker in America, scoring twice as high as General Motors. This trust wasn't based on personal relationships but on "fairness, stability, and predictability of Toyota's routines and processes." Toyota recognized that strong supplier networks served its interests better than short-term gains from exploiting suppliers. Four types of contracts work well with agile development: time-and-material contracts with highest priority features first, multistage contracts using master contracts with work orders per iteration, target-cost contracts that give teams freedom to limit scope to meet cost targets, and shared-benefit contracts that allow for mutual adaptation. The common thread is that all avoid fixing scope in detail. This approach challenges conventional wisdom that rigid scope control protects organizations, when in reality it tends to expand scope and increase costs.

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

매일 새로운 인사이트를 10만 개 이상의 레슨에서 만나보세요
단어가 강조되어 오디오와 실시간으로 동기화됩니다
내 라이브러리를 저장하고 모든 기기에서 이용하세요

9장

Finding Balance: Applying Lean Principles Thoughtfully

Lean principles should be applied with balance rather than absolutism. Eliminating waste doesn't mean eliminating all documentation; amplifying learning isn't constant mind-changing; deciding late isn't procrastination; delivering fast isn't rushing; empowering teams doesn't abandon leadership; building integrity isn't big upfront design; and seeing the whole doesn't ignore details. Practices successful elsewhere shouldn't be blindly adopted-teams must translate lean principles into practices appropriate for their specific environment, considering factors like system criticality, probability of change, and user interface needs. While lean principles work best with senior leadership support, they can be applied at any organizational level. Rather than waiting for top-down implementation, practitioners should "practice the Art of the Possible" by understanding lean thinking, creating coalitions of like-minded colleagues, addressing resistance by uncovering underlying fear and belief systems, accommodating unavoidable bureaucracy with minimal waste, taking initiative when faced with indifference, and acting quickly when given support. For large companies with existing improvement programs like Six Sigma or CMM, leverage rather than fight these initiatives, recognizing they were likely implemented to address past problems and may now be causing overcompensation. For small companies concerned with establishing discipline without overwhelming resources, start with basic professional hygiene (version control, coding standards, build automation, testing), hire skilled people, and maintain focus on doing one thing exceptionally well. When difficulties arise, apply the "see the whole" principle through three high-leverage practices: stopping everything to find and fix root causes when problems appear, identifying and focusing efforts on removing the biggest constraint, and moving focus up one level to optimize the entire system rather than individual components. Lean principles have been proven across many disciplines and will work for software development when properly applied. Proper application means employing all lean principles and using thinking tools to translate them into appropriate agile practices for each environment. The warranty becomes invalid if practices are transferred directly from other disciplines without thoughtful adaptation, or if the principles of empowering teams and building integrity are ignored.

★★★★★

린 소프트웨어 개발의 적용 완독을 축하합니다

100만 명 이상의 학습자가 사랑합니다

“23일째 매일 사용하고 있어요. 이제 제 일상의 한 부분이 되었습니다.”

jayallen

린 소프트웨어 개발의 적용의 핵심 주제

waste elimination
value stream mapping
knowledge creation
rapid feedback loops
software integrity

린 소프트웨어 개발의 적용의 명언

Amplify learning.
Decide as late as possible.
Deliver as fast as possible.
See the whole.
Software development isn't a production process-it's fundamentally about learning.

린 소프트웨어 개발의 적용의 등장인물

Mary PoppendieckAuthor and former 3M manufacturing leader
Tom PoppendieckCo-author and husband of Mary Poppendieck
Taiichi OhnoToyota executive who defined the concept of waste
Raymonde GuindonResearcher of programmer problem-solving behavior
Winston RoyceComputer scientist associated with software models

저자 소개

메리 포펜딕(Mary Poppendieck)은 린 제조 원칙을 소프트웨어 공학에 적용한 선구적인 저서인 Lean Software Development: An Agile Toolkit(린 소프트웨어 개발: 애자일 툴킷)의 공동 저자로서, 이 분야의 독보적인 권위자로 자리매김했습니다.

프로그래머이자 프로젝트 매니저 출신인 그녀의 경력은 실무적인 기술 전문성과 혁신적인 관리 관행을 잇는 가교 역할을 하며, 효율성, 낭비 제거, 애자일 협업이라는 책의 핵심 주제를 잘 보여줍니다.

그녀는 톰 포펜딕(Tom Poppendieck)과 함께 Implementing Lean Software Development: From Concept to Cash(린 소프트웨어 개발의 적용: 개념에서 현금까지)와 Leading Lean Software Development: Results Are Not the Point(린 소프트웨어 개발 리더십: 결과가 전부가 아니다)를 통해 이러한 아이디어를 확장하며 이 분야의 개척자로서의 지위를 공고히 했습니다. 이들의 워크숍과 전 세계 애자일 컨퍼런스에서의 강연은 린 사고를 통해 최적화된 워크플로우를 옹호하며 거대 IT 기업과 스타트업 모두에 큰 영향을 미쳤습니다.

Lean Software Development는 2004년 소프트웨어 개발 생산성 어워드(Software Development Productivity Award)를 수상했으며, 여러 언어로 번역되어 학계와 산업계 모두에서 널리 인용되는 현대 애자일 방법론의 초석으로 남아 있습니다.

린 소프트웨어 개발의 적용 요약 다운로드

린 소프트웨어 개발의 적용 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Lean architecture for agile software development

James O. Coplien & Gertrud Bjørnvig

Lean Impact

Ann Mei Chang

Lean UX

Jeff Gothelf

Accelerate: The Science of Lean Software and DevOps

Nicole Forsgren

Learning Agile

Andrew Stellman & Jennifer Greene

Breaking Free From Software Development's Tar Pit 책 표지

14 sources

Breaking Free From Software Development's Tar Pit

Lean Six Sigma

Michael L. George

Lean Product Playbook

Dan Olsen

이 책에 대한 FAQ

더 알아보기

학습 계획

The Diagnostic for Tool Enshittification

As software platforms increasingly prioritize monetization over utility, developers must learn to identify predatory technical patterns. This guide is essential for software architects and engineers who want to build resilient stacks and avoid becoming locked into decaying ecosystems.

1 h 30 m•3 섹션

학습 계획

Learn software dev

This comprehensive learning path takes you from programming beginner to professional software engineer, covering everything from writing your first line of code to making architectural decisions for large-scale systems. It's ideal for career changers entering tech, self-taught programmers looking to formalize their skills, or junior developers aiming to reach senior-level expertise. The structured progression ensures you build both technical proficiency and the professional mindset needed to succeed in modern software development teams.

4 h 50 m•4 섹션

학습 계획

Master Agile Scrum for Small Business

This plan is essential for small business owners and team leads looking to increase efficiency without the overhead of enterprise-level systems. It provides a roadmap for transitioning from chaotic workflows to structured, high-performing Agile environments.

4 h 4 m•4 섹션

학습 계획

Digital Transformation: Systems Over Software

This plan is essential for leaders and entrepreneurs who feel stuck in reactive cycles and want to build scalable operations. It bridges the gap between simply using digital tools and architecting a business that improves itself through systems thinking.

2 h•4 섹션

학습 계획

Bridge the Business-Tech Gap

In modern software development, technical excellence is only valuable if it drives business success. This plan is designed for engineers and product leaders who want to stop being 'order takers' and start becoming strategic partners by aligning their architecture with organizational goals.

1 h 12 m•3 섹션

학습 계획

Lead 8 Plants: Principles & Management Prep

This learning plan provides a comprehensive roadmap for mastering modern manufacturing leadership and operational efficiency. It is designed for plant managers and industrial leaders seeking to implement world-class lean strategies and drive cultural transformation across complex production environments.

5 h 34 m•4 섹션

학습 계획

Designing and Programming Software

This comprehensive path is designed for developers looking to transition from writing scripts to engineering robust, production-ready systems. It provides the essential bridge between basic syntax and complex architectural decision-making required in modern tech roles.

5 h 53 m•4 섹션

학습 계획

design leader mindset

Design leaders today must navigate beyond craft excellence to drive strategic business impact and cultural transformation. This learning plan is essential for experienced designers moving into leadership roles, current design managers seeking to elevate their strategic influence, and organizational leaders who want to build design-led cultures that foster innovation and deliver exceptional user experiences.

3 h 57 m•4 섹션

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

샌프란시스코에서 컬럼비아 대학교 동문들이 만들었습니다

LOVED BY

1,000,000+ curious minds.

4.7

avg rating

1M+ learners

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

"Instead of endless scrolling, I just hit play on BeFreed. It saves me so much time."

@Moemenn

"I never knew where to start with nonfiction—BeFreed’s book lists turned into podcasts gave me a clear path."

@Chloe, Solo founder, LA

117

"Perfect balance between learning and entertainment. Finished ‘Thinking, Fast and Slow’ on my commute this week."

@Raaaaaachelw

"Crazy how much I learned while walking the dog. BeFreed = small habits → big gains."

@Matt, YC alum

108

"Reading used to feel like a chore. Now it’s just part of my lifestyle."

@Erin, Investment Banking Associate , NYC

254

"Feels effortless compared to reading. I’ve finished 6 books this month already."

@djmikemoore

"BeFreed turned my guilty doomscrolling into something that feels productive and inspiring."

@Pitiful

4.5K

"BeFreed turned my commute into learning time. 20-min podcasts are perfect for finishing books I never had time for."

@SofiaP

"BeFreed replaced my podcast queue. Imagine Spotify for books — that’s it. 🙌"

@Jaded_Falcon

201

"It is great for me to learn something from the book without reading it."

@OojasSalunke

"The themed book list podcasts help me connect ideas across authors—like a guided audio journey."

@Leo, Law Student, UPenn

483

"Makes me feel smarter every time before going to work"

@Cashflowbubu

웹에서 BeFreed가 어떻게 논의되고 있는지 더 보기

지금 바로 학습 여정을 시작하세요

4장

린 소프트웨어 개발의 적용

개요린 소프트웨어 개발의 적용 개요

한 권의 책, 다양한 듣기 방식.

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Eliminate Waste: The Foundation of Lean Thinking

들리는 모든 단어를 눈으로 확인하세요

Amplify Learning: Software Development as Knowledge Creation

Decide as Late as Possible: Maintaining Options in an Uncertain World

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

Deliver as Fast as Possible: Speed as Competitive Advantage

Empower the Team: Unleashing Human Potential

들리는 모든 단어를 눈으로 확인하세요

Build Integrity In: Creating Cohesive Systems That Delight Users

See the Whole: Systems Thinking in Software Development

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

Finding Balance: Applying Lean Principles Thoughtfully

린 소프트웨어 개발의 적용 완독을 축하합니다

린 소프트웨어 개발의 적용의 핵심 주제

린 소프트웨어 개발의 적용의 명언

린 소프트웨어 개발의 적용의 등장인물

저자 소개

린 소프트웨어 개발의 적용 요약 다운로드

다른 사용자들도 좋아한 책

이 책에 대한 FAQ

What is Lean Software Development by Mary Poppendieck about?

Who should read Lean Software Development?

Is Lean Software Development worth reading in 2025?

What are the 7 core principles of Lean Software Development?

더 알아보기

1,000,000+ curious minds.

1,000,000+ curious minds.

한 권의 책, 다양한 듣기 방식.

The Lean Revolution: How Toyota's Manufacturing Principles Are Transforming Software Development

Eliminate Waste: The Foundation of Lean Thinking

들리는 모든 단어를 눈으로 확인하세요

Amplify Learning: Software Development as Knowledge Creation

Decide as Late as Possible: Maintaining Options in an Uncertain World

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

Deliver as Fast as Possible: Speed as Competitive Advantage

Empower the Team: Unleashing Human Potential

들리는 모든 단어를 눈으로 확인하세요

Build Integrity In: Creating Cohesive Systems That Delight Users

See the Whole: Systems Thinking in Software Development

린 소프트웨어 개발의 적용에서 더 많은 것을 얻으세요

Finding Balance: Applying Lean Principles Thoughtfully

린 소프트웨어 개발의 적용 완독을 축하합니다

다른 사용자들도 좋아한 책

더 알아보기

린 소프트웨어 개발의 적용 개요