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.

アジャイルの基本 ―チームを改善する25の習慣―

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)

『アジャイルの基本 ―チームを改善する25の習慣―』の概要

Agile Manifestoの共著者であるジェームズ・グレニングも絶賛した本書で、アジャイル手法をマスターしましょう。なぜエリートチームはScrum、XP、Lean、Kanbanを支持するのでしょうか？ソフトウェア開発を変革し、テクノロジー業界を超えて生産性革命を巻き起こしたフレームワークを、ぜひその目で確かめてください。

語り方を選ぶ

1冊の本。さまざまな聴き方。

アジャイルの基本 ―チームを改善する25の習慣―の同じアイデアを、あなたに合う声・深さ・ペースで学べます。いつでも切り替えられます。

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

聴きながら、すべての言葉を目で追えます

『アジャイルの基本 ―チームを改善する25の習慣―』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

毎日の新しい気づきを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.

聴きながら、すべての言葉を目で追えます

『アジャイルの基本 ―チームを改善する25の習慣―』の一語一語が音声に合わせてリアルタイムでハイライトされ、自然に読み進められます。

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

毎日の新しい気づきを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.

★★★★★

『アジャイルの基本 ―チームを改善する25の習慣―』を最後まで読み終えました

100万人以上の学習者に愛用されています

“23日間、毎日使い続けています。今では日課の一部です。”

jayallen

『アジャイルの基本 ―チームを改善する25の習慣―』の主要テーマ

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

『アジャイルの基本 ―チームを改善する25の習慣―』の名言

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

『アジャイルの基本 ―チームを改善する25の習慣―』の登場人物

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

著者について

『Learning Agile: Understanding Scrum, XP, Lean, and Kanban』のベストセラー著者であるアンドリュー・スティルマンとジェニファー・グリーンは、アジャイル手法とソフトウェア開発における著名な専門家です。マイクロソフト、バンク・オブ・アメリカ、MITなどの組織でチームを管理してきた20年以上の経験を持ち、彼らの活動は技術的実践とチームダイナミクスの橋渡しをしています。

『Learning Agile』はソフトウェア開発文学の金字塔であり、ScrumやKanbanなどのアジャイルフレームワークを実際のケーススタディを通じて探求しています。これは、国際的なソフトウェアチームや企業のプロジェクトにおけるアジャイル移行を主導してきた彼らの実践的な経験を反映したものです。

二人は『Head First PMP』や『Applied Software Project Management』など、学術的・専門的な現場で広く利用されている数々の影響力のある著作を共著しています。Stellman & Greene Consultingを通じて、彼らは世界中の組織にトレーニングやコーチングを提供し、実践的なアジャイル導入を強調しています。彼らの著書は世界中で数十万部を売り上げ、多言語に翻訳されており、テクノロジーおよびプロジェクト管理コミュニティにおける信頼できる発信者としての地位を確立しています。

アジャイルの基本 ―チームを改善する25の習慣―の要約をダウンロード

アジャイルの基本 ―チームを改善する25の習慣―の要約を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 セクション

学習プラン

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 セクション

学習プラン

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 セクション

学習プラン

The Systems Thinking Advantage for Founders

In the volatile world of startups, founders often fall into the trap of reactive management. This learning plan is essential for entrepreneurs who want to move beyond chaos by mastering the structural dynamics of their business. It is ideal for early-stage leaders aiming to build scalable, stable organizations through first-principles design.

1 h 30 m•3 セクション

学習プラン

The High-Growth Leadership Playbook

In fast-scaling environments, traditional management often leads to burnout and missed deadlines. This playbook is designed for high-growth leaders who need to shift from tactical oversight to strategic empowerment to sustain team performance. It provides the psychological and behavioral tools necessary to build a self-sustaining, high-energy culture.

2 h•4 セクション

学習プラン

The Architecture of Self-Mastery

This learning plan is designed for high-achievers who feel held back by physical fatigue or mental resistance. It bridges the gap between strategic thinking and biological optimization, making it ideal for professionals seeking a comprehensive upgrade to their personal effectiveness.

1 h 30 m•3 セクション

学習プラン

Influence Without the Push

This learning plan is essential for professionals who want to master persuasion without compromising integrity or damaging relationships. It is particularly beneficial for sales leaders, negotiators, and entrepreneurs who need to drive results through psychological alignment rather than force.

2 h•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がウェブ上でどのように話題になっているかをもっと見る

今すぐ学習の旅を始めよう

第6章

アジャイルの基本 ―チームを改善する25の習慣―

概要『アジャイルの基本 ―チームを改善する25の習慣―』の概要

1冊の本。さまざまな聴き方。

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

The Agile Journey: Continuous Learning and Improvement

『アジャイルの基本 ―チームを改善する25の習慣―』を最後まで読み終えました

『アジャイルの基本 ―チームを改善する25の習慣―』の主要テーマ

『アジャイルの基本 ―チームを改善する25の習慣―』の名言

『アジャイルの基本 ―チームを改善する25の習慣―』の登場人物

著者について

アジャイルの基本 ―チームを改善する25の習慣―の要約をダウンロード

他のユーザーのお気に入り

この本に関するよくある質問

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

もっと見る

1,000,000+ curious minds.

1,000,000+ curious minds.

1冊の本。さまざまな聴き方。

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

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

『アジャイルの基本 ―チームを改善する25の習慣―』をもっと深く楽しむ

The Agile Journey: Continuous Learning and Improvement

『アジャイルの基本 ―チームを改善する25の習慣―』を最後まで読み終えました

他のユーザーのお気に入り

この学習プランの一部

Learn project management for a career change

Release train engineering

もっと見る

『アジャイルの基本 ―チームを改善する25の習慣―』の概要