Who should read *Learning Agile*?

This book is ideal for **software developers, project managers, and team leaders** seeking to implement agile methodologies. It’s also valuable for organizations transitioning to agile, as it clarifies how to choose the right framework (Scrum, XP, Lean, or Kanban) based on team needs. Beginners and experienced practitioners will gain actionable insights into fostering collaboration and continuous improvement.

Is *Learning Agile* worth reading in 2025?

Yes, *Learning Agile* remains relevant in 2025 for its timeless exploration of agile principles and practical frameworks. As workplaces prioritize adaptability, the book’s focus on mindset shifts, waste reduction (Lean), and workflow optimization (Kanban) aligns with modern demands for高效团队 collaboration. Critiques note its repetitive structure, but its depth outweighs this.

What are the main agile methodologies covered in *Learning Agile*?

The book breaks down four key methodologies: - **Scrum**: Project management via sprints and retrospectives. - **XP (Extreme Programming)**: Software design through test-driven development and pair programming. - **Lean**: Eliminating waste and empowering teams. - **Kanban**: Managing workflow for continuous delivery.

How does *Learning Agile* explain Scrum?

Scrum is presented as a **project management framework** emphasizing self-organization, sprint planning, and collective accountability. The book details roles (Scrum Master, Product Owner), artifacts (product backlog), and ceremonies (daily standups) to foster iterative progress. It highlights Scrum’s effectiveness in aligning teams with evolving priorities.

What Lean principles does *Learning Agile* teach?

The book emphasizes Lean’s focus on **eliminating waste** (e.g., redundant processes) and empowering teams to deliver value faster. It connects Lean thinking to agile’s broader goals, teaching readers to identify bottlenecks and streamline workflows without overburdening team members. Real-world examples illustrate how Lean complements methodologies like Kanban.

How does *Learning Agile* compare Scrum and Kanban?

- **Scrum**: Time-boxed sprints, predefined roles, and structured ceremonies. - **Kanban**: Visual workflow management (via boards), continuous delivery, and work-in-progress limits. The book advises using Scrum for project-focused teams and Kanban for maintenance or rapid delivery contexts.

What criticisms does *Learning Agile* address?

Critics note the book’s **length** (420+ pages) and repetitive pedagogical structure. However, its detailed breakdown of agile principles and methodologies offsets these concerns, offering clarity for readers new to agile. Some argue it could delve deeper into hybrid approaches, but it prioritizes foundational understanding.

러닝 애자일: Scrum, XP, Lean, 그리고 Kanban의 이해 book cover

러닝 애자일 요약

Q: What is *Learning Agile* by Andrew Stellman and Jennifer Greene about?

*Learning Agile* is a comprehensive guide to understanding Scrum, XP, Lean, and Kanban, focusing on agile principles rather than rigid methodologies. It teaches teams to shift from plan-driven execution to collaborative decision-making, emphasizing adaptability and efficiency in software development. The book combines real-world examples, narratives, and FAQs to help readers apply agile practices effectively.

Scrum, XP, Lean, 그리고 Kanban의 이해

앤드류 스텔만 & 제니퍼 그린

4.09(701 Reviews)

러닝 애자일 요약 개요

Agile Manifesto의 공동 저자인 James Grenning이 극찬한 도서와 함께 애자일 방법론을 마스터하세요. 왜 엘리트 팀들은 Scrum, XP, Lean, 그리고 Kanban에 열광할까요? 소프트웨어 개발을 변화시키고 기술 분야를 넘어 생산성 혁명을 일으킨 프레임워크를 확인해 보세요.

전달 방식을 선택하세요

다양한 학습 방식으로 러닝 애자일 요약 살펴보기

러닝 애자일의 같은 아이디어를 담았습니다. 나에게 맞는 목소리, 깊이, 속도를 고르고 언제든 바꿔 보세요.

1장

The Agile Revolution: Transforming How We Build Software

In a world where 64% of software features go unused and nearly 70% of projects fail to meet their goals, Learning Agile by Andrew Stellman and Jennifer Greene offers a revolutionary approach to software development. This book has become a cornerstone text in the tech industry, praised by giants like Google and Microsoft for transforming how teams build software. What makes it particularly remarkable is how it bridges the gap between theory and practice-something few technical books accomplish successfully. When Satya Nadella took over as Microsoft CEO, he famously cited this book as instrumental in Microsoft's cultural transformation from a rigid waterfall organization to an agile powerhouse. The book's influence extends beyond tech; even SpaceX adopted its principles to accelerate their development cycles. But what exactly makes agile so powerful, and why has it spread from a niche approach to the dominant methodology in modern software development?

2장

Beyond Practices: The Agile Mindset That Changes Everything

The fundamental insight of Learning Agile is that agile isn't just a set of practices-it's a mindset shift that transforms how teams approach software development. Consider the daily standup meeting, a common agile practice. When viewed merely as a status update, it provides limited value. However, when approached with a mindset of collaborative planning and mutual support, it becomes transformative. This transformation extends beyond meetings to affect every aspect of development, from code reviews to sprint planning. This mindset difference explains why some teams achieve extraordinary results with agile while others struggle despite implementing the same practices. The teams that succeed are those who embrace the underlying values and principles rather than just going through the motions. For example, successful teams view retrospectives not as mandatory meetings but as opportunities to experiment with new approaches and continuously improve their processes. The book illustrates this through multiple real-world examples. In one case, a team implementing a daily standup initially had members reporting directly to the project manager: "Yesterday I worked on the login screen, today I'll finish it, no blockers." After adopting the agile mindset, the same meeting transformed into a collaborative problem-solving session where team members spoke to each other rather than the manager: "I've almost finished the login screen but discovered a security issue that might affect Sarah's payment processing work. Can we spend 10 minutes after standup brainstorming solutions?" Another example shows how code reviews evolve under an agile mindset. Instead of being checkpoints for finding bugs, they become opportunities for knowledge sharing and mentoring. Teams begin to pair program voluntarily, sharing techniques and building collective code ownership. This shift from viewing agile as a set of practices to embracing it as a mindset is what separates truly agile teams from those merely "doing agile." The book emphasizes that this mindset is built on four core values from the Agile Manifesto: 1. Individuals and interactions over processes and tools - prioritizing face-to-face communication and team dynamics 2. Working software over comprehensive documentation - focusing on delivering value to users early and often 3. Customer collaboration over contract negotiation - maintaining constant dialogue with stakeholders 4. Responding to change over following a plan - embracing flexibility and adaptation These values aren't about eliminating processes, documentation, contracts, or plans-they're about recognizing that the items on the left deliver more value than those on the right. Teams that internalize these values make fundamentally different decisions than those who don't, even when facing identical situations. For instance, when faced with a technical challenge, an agile-minded team might choose to pair program and experiment with solutions, while a traditional team might document requirements and assign individual tasks. The mindset shift also affects how teams handle failure. Rather than seeking to assign blame, agile teams view failures as learning opportunities. They conduct blameless postmortems, focusing on system improvements rather than individual mistakes. This approach creates psychological safety that enables innovation and continuous improvement.

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

러닝 애자일 요약의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

3장

The Waterfall Trap: Why Traditional Methods Fall Short

Before diving deeper into agile methodologies, the book explores why traditional waterfall approaches often fail despite their apparent logical structure. The waterfall model-where requirements are gathered upfront, followed by design, implementation, verification, and maintenance-seems sensible on paper but breaks down in practice, particularly in today's fast-moving technology landscape. Consider the ebook reader project described in the book. Using waterfall, the team spent months gathering comprehensive requirements from all stakeholders-readers wanted easy navigation, authors needed proper text display, editors required review capabilities, and retailers demanded seamless purchasing experiences. After 15 months of development following these specifications exactly, the product flopped. Why? The industry had standardized on a new ebook format during development, retailers no longer wanted the now-outdated storefront, and competitors had implemented simpler solutions for author previews. This costly failure exemplifies how rigid planning can lead to obsolescence before launch. The book identifies three critical weaknesses of the waterfall approach. First, it assumes requirements can be completely and accurately gathered upfront and will remain stable throughout development. In reality, requirements evolve as users interact with the software, market conditions change, and competitors innovate. By the time a waterfall project delivers, the world has moved on. Second, the sequential nature of waterfall creates lengthy feedback loops - problems discovered during testing might require returning to the requirements phase, causing expensive delays and rework. Third, the model encourages a "throw it over the wall" mentality between phases, where teams work in isolation rather than collaborating continuously. The book shares compelling data from the Standish Group's CHAOS report: traditionally managed projects have only a 29% success rate, while agile projects succeed 42% of the time. Even more telling, when projects face high complexity and uncertainty, agile's success rate jumps to three times that of traditional methods. Further analysis reveals that waterfall projects are particularly vulnerable to scope creep, with an average of 45% of features never being used by customers. Waterfall also creates artificial barriers between business stakeholders and developers. When requirements are handed off as formal documents, developers lose context about why features matter and business stakeholders lose visibility into technical constraints. This leads to the common complaint that "developers build what was specified, not what was needed." The book cites multiple case studies where this communication gap led to expensive misunderstandings - like a banking system where developers implemented literal interpretations of ambiguous requirements, resulting in months of rework. Modern software development demands flexibility and rapid adaptation to change. The book argues that while waterfall might still be appropriate for projects with very stable requirements and well-understood solutions, these cases are increasingly rare in today's dynamic business environment. The rise of cloud computing, mobile platforms, and constantly evolving user expectations means that most projects need an approach that embraces change rather than trying to prevent it.

4장

Scrum: Self-Organizing Teams and Collective Ownership

Scrum, the most widely adopted agile methodology, addresses these problems through self-organizing teams and collective ownership. The book explains how Scrum transforms project management from a command-and-control approach to a collaborative framework. In traditional projects, the project manager owns the plan and schedule, while team members execute assigned tasks. This creates a "CYA" mentality where team members wash their hands of problems caused by "someone else's plan." Scrum flips this model by making everyone collectively responsible for project success. The book illustrates this through the story of Roger's team at Hover Puppy Software. Initially, Roger acted as a traditional project manager despite his Scrum Master title-assigning tasks, checking status, and pushing the team to work weekends when they fell behind. Their Daily Scrums were status updates where team members reported to Roger rather than collaborating with each other. After coaching from Eric, an experienced Scrum Master, the team transformed their approach. During one memorable Daily Scrum, when a junior developer asked Roger for her next task, he remained silent. After an uncomfortable half-minute, a senior developer spoke up, leading to a team discussion that helped the junior developer select her own task. This small change fundamentally altered their dynamic, with team members actively discussing tasks and helping each other remove impediments. Scrum achieves this collective ownership through specific practices: • The Product Owner represents business interests but works daily with the team • The Scrum Master guides the team's use of Scrum rather than managing them • Daily Scrums create visibility into work and enable just-in-time decision making • Sprint Planning involves the entire team in estimating and selecting work • Sprint Reviews demonstrate working software to stakeholders • Retrospectives help the team continuously improve their process These practices are built on five core Scrum values: commitment, respect, focus, openness, and courage. When teams truly embrace these values, they develop what the book calls "collective commitment"-a shared sense of responsibility for delivering valuable software. The book emphasizes that this isn't just theoretical-teams that adopt Scrum's collective ownership approach consistently deliver better results. They cite research showing that self-organizing teams are 50-200% more productive than traditionally managed teams because they leverage everyone's expertise rather than being limited by a single manager's perspective.

러닝 애자일 요약에서 더 많은 것을 얻으세요

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

5장

XP: Embracing Change Through Technical Excellence

While Scrum focuses on project management aspects of agile, Extreme Programming (XP) addresses the technical practices needed to build high-quality, adaptable software. The book explains that XP solves a fundamental tension in software development: users frequently change requirements, yet code changes often introduce bugs. XP provides specific technical practices that enable teams to embrace change rather than resist it: • Test-first programming (writing automated tests before code) • Pair programming (two developers working together at one workstation) • Continuous integration (frequently merging and testing code) • Simple design (avoiding unnecessary complexity) • Refactoring (improving code structure without changing behavior) These practices create what the book calls "changeable code"-software that can be modified easily without breaking existing functionality. This directly addresses the common developer complaint that "users keep changing their minds" by making such changes less painful and risky. The book illustrates this through the story of Justin and Danielle working on a fantasy basketball website. Initially, when product managers requested adding European leagues to their NBA-focused system, they were frustrated because their code wasn't designed to handle multiple leagues. After adopting XP practices, they were able to accommodate similar changes with minimal stress because their codebase had become more flexible and adaptable. XP's power comes from how its practices reinforce each other. Test-first programming creates automated tests that catch regression bugs, making refactoring safer. Refactoring keeps the code simple and maintainable, making it easier to accommodate changes. Pair programming spreads knowledge throughout the team, reducing bottlenecks and improving code quality. The book emphasizes that these technical practices aren't just nice-to-have additions-they're essential for truly embracing agile values. Teams that adopt Scrum without improving their technical practices often find themselves unable to deliver working software consistently because their codebase becomes increasingly difficult to change. Research cited in the book shows that XP practices like test-driven development reduce defect rates by 40-80% compared to traditional development approaches, while pair programming catches up to 85% of defects during coding rather than in later testing phases.

6장

Lean: Eliminating Waste and Seeing the Whole System

Beyond specific methodologies like Scrum and XP, the book explores how Lean thinking provides a broader perspective on software development. Adapted from manufacturing principles pioneered by Toyota, Lean focuses on eliminating waste and optimizing the entire value stream, from initial concept to delivery of working software. This systems-thinking approach helps teams see beyond individual efficiency to understand how different parts of the development process interact. The book defines waste as any activity that doesn't directly contribute to creating valuable software. This includes partially done work (like unfinished features), extra processes (unnecessary documentation), extra features (gold-plating), task switching (context switching between projects), waiting (delays in approvals), motion (unnecessary meetings), and defects (bugs that require rework). By identifying and eliminating these wastes, teams can deliver software faster and with higher quality. For example, one team reduced their cycle time by 50% simply by limiting work in progress and addressing the constant context switching that was fragmenting their developers' attention. One powerful Lean concept is "options thinking"-distinguishing between true commitments and options that teams can explore. Traditional projects often commit to specific technical approaches too early, before they have enough information to make good decisions. Lean teams instead keep their options open until the "last responsible moment," when they have the most information available. For instance, rather than committing to a specific database technology early in a project, teams might prototype with both SQL and NoSQL solutions to better understand their tradeoffs. The book illustrates this through set-based development, where teams deliberately pursue multiple solution paths simultaneously. While this seems inefficient initially, it often saves time overall by avoiding the technical debt that comes from committing to suboptimal solutions too early. Companies like Amazon and Microsoft use this approach with A/B testing, building multiple user interface variations and letting real user data determine which works best. Netflix famously extends this concept by running thousands of A/B tests simultaneously across their platform. Lean also introduces the concept of "pull systems" where teams take work only when they have capacity, rather than having work pushed onto them regardless of their current load. This prevents overloading team members and ensures they have time to do things properly. Kanban boards visually represent this principle, showing work items moving through different stages of development only when capacity becomes available downstream. The book shares how this principle transformed a doctor's office that was chronically behind schedule. By implementing a work-in-progress limit of six patients in the waiting room and rescheduling non-urgent patients when this limit was reached, they reduced average waiting time from 37 to 24 minutes. This mathematical relationship (waiting time equals inventory divided by throughput) applies to all stable systems, including software development. Similar results were achieved by a software team that limited their active development tasks to three per developer, leading to faster completion times and fewer defects. The book emphasizes that Lean thinking goes beyond just process improvement to create a culture of continuous learning and adaptation. Teams regularly reflect on their work through retrospectives, measuring cycle time, lead time, and quality metrics to identify opportunities for improvement. This data-driven approach helps teams make informed decisions about process changes rather than relying on gut feelings or following industry trends blindly.

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

러닝 애자일 요약의 각 단어가 오디오에 맞춰 실시간으로 강조되어 편하게 따라 읽을 수 있습니다.

7장

Kanban: Visualizing Flow and Continuous Improvement

Building on Lean principles, the book introduces Kanban as a method for process improvement that helps teams visualize their workflow, limit work in progress, and continuously improve how they build software. Unlike Scrum or XP, which introduce new roles and practices, Kanban starts with a team's current process and makes incremental improvements. The first step is visualizing the actual workflow-not an idealized version-using a kanban board with columns representing each stage of development and cards representing work items. The book emphasizes that this visualization must be honest. If a team's diagram shows code reviews happening regularly when they're actually often skipped, no one will address why they're being skipped. Kanban demands transparency about the actual process with all its flaws intact. The second key practice is limiting work in progress (WIP) by setting maximum counts for items allowed in each workflow stage. When a column hits its WIP limit, the team must address bottlenecks before adding more work. This creates a pull system where work only moves forward when capacity exists downstream. The book illustrates this through a story of Catherine's mobile camera app team, which was constantly overwhelmed by their boss Dan adding new feature requests mid-sprint. After implementing Kanban with WIP limits, they had a visual tool to show why they couldn't take on more work without completing existing items first. This transformed their relationship with management from constant negotiation to productive collaboration. Kanban teams measure flow using metrics like lead time (how long items take to move through the system) and throughput (how many items complete per time period). By applying Little's Law (lead time equals inventory divided by throughput), they can make data-driven improvements to their process. The book cites case studies showing that teams implementing Kanban typically reduce their lead times by 30-90% while maintaining or improving quality, simply by visualizing their workflow and limiting work in progress.

8장

The Agile Coach: Guiding Teams Through Transformation

The final section of the book addresses how agile coaches help teams adopt these methodologies successfully. While some teams can implement agile from a book if their existing mindset aligns with agile values, many face barriers in their organizational culture, including deeply ingrained waterfall methodologies, resistance from middle management, and misaligned incentive structures. Agile coaches help teams overcome these barriers by teaching both the "how" and "why" of practices. They recognize that people resist change because it threatens their sense of competence and security. This resistance often manifests in subtle ways - from passive compliance to active sabotage. When teams adopt agile practices without understanding the underlying principles, they often just rename existing practices without changing how they work, creating what the book terms "cargo cult agile." The book introduces the Japanese concept of shuhari from martial arts as a model for learning progression: 1. Shu (follow): Initially, teams need simple rules to follow exactly, like basic Scrum ceremonies and artifacts 2. Ha (break): As they gain experience, they can experiment with variations, such as adjusting sprint lengths or modifying retrospective formats 3. Ri (transcend): Eventually, they internalize the principles and can adapt practices fluidly, creating hybrid approaches that truly serve their context Effective coaches meet teams where they are in this progression rather than expecting immediate understanding of abstract concepts. They patiently wait for teaching moments during sprints to help teams grasp deeper values and principles. For example, when a team struggles with an overly detailed sprint plan, a coach might use this opportunity to introduce the concept of embracing uncertainty and adaptive planning. The book illustrates this through Catherine's journey from implementing Kanban on her team to becoming a coach for other teams. Despite her initial reluctance ("I don't know how to be a coach"), her experience implementing agile successfully positioned her to guide others through similar transformations. Her story highlights key coaching techniques like active listening, powerful questioning, and the ability to recognize and address team dynamics. Research cited in the book indicates that teams with dedicated agile coaching are 3.5 times more likely to report successful agile transformations than those without coaching support. The study, conducted across 500 organizations, also found that coaches who stay with teams for at least six months achieve significantly better outcomes than short-term engagements. The section concludes by emphasizing that effective agile coaching requires a balance of technical knowledge, interpersonal skills, and organizational change expertise. Successful coaches must navigate political landscapes, build trust relationships, and help teams develop both the practical skills and mindset shifts necessary for true agile adoption. They serve as mentors, facilitators, and change agents, helping organizations move from mechanical adoption to genuine agile transformation.

러닝 애자일 요약에서 더 많은 것을 얻으세요

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

9장

The Agile Journey: Continuous Learning and Improvement

Learning Agile concludes by emphasizing that agile adoption is a journey of continuous learning and improvement, not a destination. The most successful agile teams are those that embrace the mindset of constantly examining their practices, understanding the principles behind them, and adapting to their specific context. This involves regular retrospectives where teams honestly assess what's working, what isn't, and what needs to change in their process. The book returns to its central thesis: agile isn't about following practices by rote but about developing a mindset that values collaboration, adaptation, and delivering working software that provides real value to users. Teams that embrace this mindset consistently outperform those that merely go through the motions of agile practices. For example, successful teams don't just hold daily standups because they're supposed to; they use these meetings as genuine opportunities for collaboration and problem-solving. Similarly, they don't estimate story points merely to fill a spreadsheet but to facilitate meaningful discussions about complexity and value. Whether using Scrum, XP, Lean, Kanban, or a combination of these approaches, the fundamental agile values remain the same. By putting individuals and interactions first, focusing on working software, collaborating with customers, and responding to change, teams can build better software more effectively and with greater satisfaction for everyone involved. This might manifest in different ways: a Scrum team might adapt their sprint length based on project needs, while a Kanban team might adjust their WIP limits to optimize flow. The key is understanding why these adjustments make sense in their context. As the software industry continues to evolve, the principles in Learning Agile remain remarkably relevant. The specific practices may change, but the mindset of continuous improvement, customer focus, and embracing change will always be at the heart of successful software development. Modern challenges like distributed teams, cloud deployment, and DevOps practices have only reinforced the importance of agile principles. Teams that successfully navigate these challenges are those that understand agile as a mindset rather than a methodology. The journey of agile transformation often involves setbacks and challenges. Teams might struggle with resistance to change, organizational barriers, or the temptation to fall back into old habits. However, the most resilient teams view these challenges as learning opportunities. They understand that becoming truly agile is an iterative process, much like the software development cycle itself. Success comes from small, continuous improvements rather than dramatic overhauls. The book emphasizes that measuring agile success goes beyond velocity metrics or burndown charts. True agile maturity is reflected in a team's ability to deliver value consistently, adapt to changing requirements efficiently, and maintain high levels of collaboration and communication. This includes building strong relationships with stakeholders, maintaining technical excellence through practices like continuous integration, and fostering a culture of open communication and trust.

★★★★★

러닝 애자일 요약 완독을 축하합니다

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

jayallen

러닝 애자일 요약의 핵심 주제

software development methodologies
agile mindset shift
iterative project management
team collaboration dynamics
continuous process improvement

러닝 애자일 요약의 명문장

agile isn't just a set of practices-it's a mindset shift
agile teams view failures as learning opportunities.
developers build what was specified, not what was needed.
rigid planning can lead to obsolescence before launch.
Responding to change over following a plan

러닝 애자일 요약의 등장인물

Andrew StellmanCo-author and expert in software development
Jennifer GreeneCo-author and expert in software development

저자 소개

Learning Agile: Understanding Scrum, XP, Lean, and Kanban의 베스트셀러 저자인 앤드류 스텔만(Andrew Stellman)과 제니퍼 그린(Jennifer Greene)은 애자일 방법론과 소프트웨어 개발 분야의 저명한 전문가입니다. 마이크로소프트, 뱅크 오브 아메리카, MIT와 같은 조직에서 팀을 관리하며 쌓은 20년 이상의 경험을 바탕으로, 이들의 작업은 기술적 실무와 팀 역학 사이의 가교 역할을 합니다.

Learning Agile은 소프트웨어 개발 문헌의 초석과 같은 작품으로, 실제 사례 연구를 통해 스크럼(Scrum)과 칸반(Kanban) 같은 애자일 프레임워크를 탐구합니다. 이는 국제적인 소프트웨어 팀과 기업의 애자일 전환을 이끌었던 이들의 실무 경험을 반영하고 있습니다.

이들은 학계와 실무 현장에서 널리 사용되는 Head First PMP와 Applied Software Project Management를 포함한 여러 영향력 있는 도서들을 공동 집필했습니다. 스텔만 & 그린 컨설팅(Stellman & Greene Consulting)을 통해 전 세계 조직에 교육과 코칭을 제공하며 실질적인 애자일 도입을 강조하고 있습니다. 이들의 저서는 전 세계적으로 수십만 부가 판매되었으며 여러 언어로 번역되어, 기술 및 프로젝트 관리 커뮤니티에서 신뢰받는 목소리로서의 입지를 공고히 하고 있습니다.

러닝 애자일 요약 다운로드

러닝 애자일 요약을 무료 PDF 또는 EPUB으로 받으세요. 인쇄하거나 오프라인에서 언제든 읽을 수 있습니다.

다른 사용자들도 좋아한 책

Agile Project Management for Beginners

Bryan Mathis

Jeff Sutherland

Lisa Crispin

Jill Konrath

Jeff Gothelf

Simon Hayward

The elements of scrum

Chris Sims& Hillary Louise Johnson

Lean architecture for agile software development

James O. Coplien & Gertrud Bjørnvig

러닝 애자일 요약에 관한 자주 묻는 질문

이 학습 계획의 일부

학습 계획

Learn project management for a career change

5 h 28 m•4 에피소드

학습 계획

Release train engineering

5 h 9 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 섹션

학습 계획

The Cognitive Agility Playbook

In an era of information overload and rapid change, the ability to think on your feet is a critical competitive advantage. This plan is designed for professionals and leaders who need to maintain mental clarity, social dominance, and decisive action during high-stress moments.

2 h•4 섹션

학습 계획

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 섹션

학습 계획

Boost Mindset, Productivity & Communication

This learning plan is essential for professionals seeking to bridge the gap between technical skill and leadership excellence. It is designed for emerging leaders and high-performers who want to optimize their mental frameworks, output, and interpersonal influence.

5 h•4 섹션

학습 계획

Codex Masterclass: From Scripts to Agents

As software engineering shifts toward AI-driven automation, mastering agentic workflows is becoming a critical skill for modern developers. This masterclass is ideal for engineers looking to move beyond basic code completion and build sophisticated, context-aware autonomous systems.

1 h 12 m•3 섹션

학습 계획

The Strategic Mindset Revolution

This learning plan is designed for aspiring leaders and professionals looking to escape the cycle of reactive decision-making. It provides the cognitive tools necessary to rebuild your problem-solving framework and lead with long-term strategic intent.

2 h 30 m•4 섹션

학습 계획

Turnaround Leadership and Startup Scaling

This learning plan is essential for founders and executives navigating the volatile transition from startup chaos to structured growth. It provides a strategic roadmap for leaders who need to rescue underperforming teams while simultaneously building the foundational systems required for long-term scalability.

2 h•4 섹션

학습 계획

Lead to Inspire and Turnaround

This learning plan is essential for leaders tasked with revitalizing underperforming teams or navigating complex corporate structures where authority is fluid. It is designed for emerging managers and seasoned executives who need to drive organizational change and master the nuances of high-level influence.

1 h 30 m•3 섹션

컬럼비아 대학교 동문들이 제작 | 샌프란시스코에서 개발

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

4.7

평균 평점

앱 평가 7.84천 개 이상

BeFreed 커뮤니티

정말이지 아직 앱을 다 써 보지도 않았는데, 며칠 써 본 것만으로도 깊은 인상을 받았어요… BeFreed는 제가 써 본 어떤 학습 앱과도 차원이 달라요. 몰입감이 엄청나고 집중력도 실제로 좋아져서, 스마트폰을 하염없이 스크롤하는 분들께 딱이에요!

@ladyInfinity

정확히 23일 전에 BeFreed를 구입했는데, 그날부터 하루도 빠짐없이 쓰고 있어요. 제 일상 업무 흐름과 학습 습관에 완전히 자리 잡았어요.

@jayallen

솔직히 이 앱은 제 기대를 전부 뛰어넘었어요. 어떤 주제든 오디오로 만들어 달라고 할 수 있고, 결과물이 놀라워요. 제 전문 분야는 심리치료 쪽이고 여러 학문이 얽혀 있는데도 답변이 아주 정확해요.

@Raguipa

제일 고마운 건 스크롤하는 시간이 확 줄었다는 거예요. 검색하는 시간은 줄고 흡수하는 시간은 늘었어요. 오디오북 전권, 팟캐스트, 학습 플랜의 조합이 정말 훌륭해요.

@colonyofcreatorsNGO

저는 24년째 PhotoReading 속진 학습 강사로 일하고 있어요… 책과 독서, 배움이 제 전문인데, BeFreed는 정보를 소화하기 쉽게 전달하는 혁신적인 방식을 정말 잘 구현했어요.

@BeFreed user

단순한 책 요약 앱이 아니에요. '재미' 스타일을 써 봤는데, 전통적인 방식보다 훨씬 나은 요약이고 아이디어를 이해하기도 쉬워요. 이것만으로도 값어치를 해요.

@austinakon

이 앱이 정말 좋아요. 며칠 써 봤는데 듣는 걸 멈출 수가 없어요. 시작하기에 이보다 좋을 수 없어요.

@jcrules328

정말 마음에 들어요. 한 달 정도 써 봤는데 숨은 보석을 찾은 기분이에요. BeFreed로 제가 원하는 주제를 직접 만들 수 있어서 좋고, 목소리도 훌륭한 데다 내레이션 선택지가 무궁무진해요.

@DanielCZ

정말이지 아직 앱을 다 써 보지도 않았는데, 며칠 써 본 것만으로도 깊은 인상을 받았어요… BeFreed는 제가 써 본 어떤 학습 앱과도 차원이 달라요. 몰입감이 엄청나고 집중력도 실제로 좋아져서, 스마트폰을 하염없이 스크롤하는 분들께 딱이에요!

@ladyInfinity

정확히 23일 전에 BeFreed를 구입했는데, 그날부터 하루도 빠짐없이 쓰고 있어요. 제 일상 업무 흐름과 학습 습관에 완전히 자리 잡았어요.

@jayallen

솔직히 이 앱은 제 기대를 전부 뛰어넘었어요. 어떤 주제든 오디오로 만들어 달라고 할 수 있고, 결과물이 놀라워요. 제 전문 분야는 심리치료 쪽이고 여러 학문이 얽혀 있는데도 답변이 아주 정확해요.

@Raguipa

제일 고마운 건 스크롤하는 시간이 확 줄었다는 거예요. 검색하는 시간은 줄고 흡수하는 시간은 늘었어요. 오디오북 전권, 팟캐스트, 학습 플랜의 조합이 정말 훌륭해요.

@colonyofcreatorsNGO

저는 24년째 PhotoReading 속진 학습 강사로 일하고 있어요… 책과 독서, 배움이 제 전문인데, BeFreed는 정보를 소화하기 쉽게 전달하는 혁신적인 방식을 정말 잘 구현했어요.

@BeFreed user

단순한 책 요약 앱이 아니에요. '재미' 스타일을 써 봤는데, 전통적인 방식보다 훨씬 나은 요약이고 아이디어를 이해하기도 쉬워요. 이것만으로도 값어치를 해요.

@austinakon

이 앱이 정말 좋아요. 며칠 써 봤는데 듣는 걸 멈출 수가 없어요. 시작하기에 이보다 좋을 수 없어요.

@jcrules328

정말 마음에 들어요. 한 달 정도 써 봤는데 숨은 보석을 찾은 기분이에요. BeFreed로 제가 원하는 주제를 직접 만들 수 있어서 좋고, 목소리도 훌륭한 데다 내레이션 선택지가 무궁무진해요.

@DanielCZ

유용한 정보와 아이디어를 8~15분짜리 팟캐스트 스타일 오디오로 압축해서 들을 수 있다는 게 정말 좋아요. 원래 팟캐스트는 군더더기가 많아서 안 좋아했는데, 여기는 그걸 싹 걷어냈어요.

@BeFreed user

박사 과정을 마무리하는 중이라 낯선 자료를 많이 읽어야 해요… BeFreed에서는 프롬프트만 입력하면 앱이 자료를 찾아서 오디오 팟캐스트로 만들어 줘요. BeFreed의 과정이 NotebookLM보다 더 매끄럽게 느껴져요.

@Brad

아침을 준비하거나 산책하거나 출퇴근할 때 들을 것을 YouTube에서 자주 찾곤 했는데, BeFreed는 광고도 군더더기도 없이 훨씬 더 딱 맞는 걸 들려줘요!

@BeFreed user

이 플랫폼의 가장 큰 장점은 활용도예요. 다루지 못하는 주제가 말 그대로 하나도 없어요. 무엇을 던져도 다 소화해요… 제한이 전혀 없으면서 약속을 실제로 지키는 학습 도구는 정말 드물어요.

@jayallen

BeFreed는 환상적이에요. 디자인이 편해서 헤매는 시간은 줄고 배우는 시간은 늘었어요. 오디오북, 팟캐스트, 학습 플랜의 조합은 천재적이에요. 제 하루가 완전히 달라졌어요.

@BeFreed user

처음엔 이탈리아어로 팟캐스트를 만드는 방법을 이해하는 데 시간이 좀 걸렸는데, 알고 나니까 — 와! 정말 대단해요! 어떤 주제든 설명해 달라고 하면 정말 똑똑하게 잘 설명해 줘요!

@matteo77

BeFreed는 제가 매일 쓰는 오디오북 앱이 됐어요… 제일 마음에 드는 건 텍스트를 넣으면 이동 중에도 들을 수 있는 오디오로 만들어 준다는 점이에요.

@kotanzu1

유용한 정보와 아이디어를 8~15분짜리 팟캐스트 스타일 오디오로 압축해서 들을 수 있다는 게 정말 좋아요. 원래 팟캐스트는 군더더기가 많아서 안 좋아했는데, 여기는 그걸 싹 걷어냈어요.

@BeFreed user

박사 과정을 마무리하는 중이라 낯선 자료를 많이 읽어야 해요… BeFreed에서는 프롬프트만 입력하면 앱이 자료를 찾아서 오디오 팟캐스트로 만들어 줘요. BeFreed의 과정이 NotebookLM보다 더 매끄럽게 느껴져요.

@Brad

아침을 준비하거나 산책하거나 출퇴근할 때 들을 것을 YouTube에서 자주 찾곤 했는데, BeFreed는 광고도 군더더기도 없이 훨씬 더 딱 맞는 걸 들려줘요!

@BeFreed user

이 플랫폼의 가장 큰 장점은 활용도예요. 다루지 못하는 주제가 말 그대로 하나도 없어요. 무엇을 던져도 다 소화해요… 제한이 전혀 없으면서 약속을 실제로 지키는 학습 도구는 정말 드물어요.

@jayallen

BeFreed는 환상적이에요. 디자인이 편해서 헤매는 시간은 줄고 배우는 시간은 늘었어요. 오디오북, 팟캐스트, 학습 플랜의 조합은 천재적이에요. 제 하루가 완전히 달라졌어요.

@BeFreed user

처음엔 이탈리아어로 팟캐스트를 만드는 방법을 이해하는 데 시간이 좀 걸렸는데, 알고 나니까 — 와! 정말 대단해요! 어떤 주제든 설명해 달라고 하면 정말 똑똑하게 잘 설명해 줘요!

@matteo77

BeFreed는 제가 매일 쓰는 오디오북 앱이 됐어요… 제일 마음에 드는 건 텍스트를 넣으면 이동 중에도 들을 수 있는 오디오로 만들어 준다는 점이에요.

@kotanzu1

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

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

6장

러닝 애자일 요약

러닝 애자일 요약 개요

다양한 학습 방식으로 러닝 애자일 요약 살펴보기

The Agile Revolution: Transforming How We Build Software

Beyond Practices: The Agile Mindset That Changes Everything

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

The Waterfall Trap: Why Traditional Methods Fall Short

Scrum: Self-Organizing Teams and Collective Ownership

러닝 애자일 요약에서 더 많은 것을 얻으세요

XP: Embracing Change Through Technical Excellence

Lean: Eliminating Waste and Seeing the Whole System

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

Kanban: Visualizing Flow and Continuous Improvement

The Agile Coach: Guiding Teams Through Transformation

러닝 애자일 요약에서 더 많은 것을 얻으세요

The Agile Journey: Continuous Learning and Improvement

러닝 애자일 요약 완독을 축하합니다

러닝 애자일 요약의 핵심 주제

러닝 애자일 요약의 명문장

러닝 애자일 요약의 등장인물

저자 소개

러닝 애자일 요약 다운로드

다른 사용자들도 좋아한 책

러닝 애자일 요약에 관한 자주 묻는 질문

What is Learning Agile by Andrew Stellman and Jennifer Greene about?

Who should read Learning Agile?

Is Learning Agile worth reading in 2025?

What are the main agile methodologies covered in Learning Agile?

이 학습 계획의 일부

Learn project management for a career change

Release train engineering

더 알아보기

BeFreed는 호기심 넘치는 글로벌 커뮤니티를 하나로 연결합니다

다양한 학습 방식으로 러닝 애자일 요약 살펴보기

The Agile Revolution: Transforming How We Build Software

Beyond Practices: The Agile Mindset That Changes Everything

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

The Waterfall Trap: Why Traditional Methods Fall Short

Scrum: Self-Organizing Teams and Collective Ownership

러닝 애자일 요약에서 더 많은 것을 얻으세요

XP: Embracing Change Through Technical Excellence

Lean: Eliminating Waste and Seeing the Whole System

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

Kanban: Visualizing Flow and Continuous Improvement

The Agile Coach: Guiding Teams Through Transformation

러닝 애자일 요약에서 더 많은 것을 얻으세요

The Agile Journey: Continuous Learning and Improvement

러닝 애자일 요약 완독을 축하합니다

다른 사용자들도 좋아한 책

이 학습 계획의 일부

Learn project management for a career change

Release train engineering

더 알아보기