Agility

Agile is something you are, not something you do. Agile means flexible, adaptable, nimble. That's your goal: agility. Agile is not a proscribed set of practices. It's a culture and a set of principles from which effective process can emerge. You can't become agile simply by learning Scrum. A successful Agile transition impacts every aspect of your company and how it works.

This course

This class introduces you to true agility—the ability to quickly and effectively handle change in both requirements and the market. The course focuses on the practical. You'll learn Agile approaches to planning, governance, development, and more—everything you need to achieve real agility in your organization. The course will save your organization the millions that you'd otherwise spend flailing around, and can trim years off the transition effort by eliminating all the false starts.

This class is perfect if you're just getting started, but its also exactly what you need if you're a Scrum shop or practitioner and want to up your game. Scrum is one small gear in a big machine with a lot of moving parts, and all of those parts are interconnected. You need to understand the whole machine to be successful, and that's what you'll learn in this class: everything you need to succeed.

If you're an engineer

  • You'll learn how to work more effectively to build software that actually delights your customers.
  • You'll learn lots of practical details that you can apply immediately to your day-to-day work.
  • You'll learn why we do the things we do by looking at the key principles of Lean manufacturing that underlie Agile thinking.
  • And of course you'll learn how to actually build software in an flexible way that's not tied to a single process or framework. In fact, You'll learn how all three of the big processes—Scrum, XP, and Kanban—work, and you'll learn how to craft custom processes that go way beyond Scrum in effectiveness.

If you're an executive or manager

  • You'll learn what being agile really means and how to smoothly transition your company to true agility.
  • You'll learn how to plan in a world where requirements are constantly changing, so estimates are never accurate enough to be valuable.
  • You'll learn how to build a scaleable company culture that lets agility thrive, and you'll learn how to support your teams so that they can work at maximum efficiency.

If you're just getting started

  • You'll be able to hit the ground running in an Agile organization.
  • Your company can assess your knowledge with a nontrivial essay-based exam that actually *means* something.

What you'll learn

  • You'll start by learning first principles: how Lean works, for example, and how does the Agile Manifesto actually apply to the real workplace. Then you'll learn to apply those principles to develop processes that work for you, and work vastly better than by-the-book Scrum and other canned processes.
  • You'll learn how these concepts affect the business itself, from organization to governance practice to how you should hire. We'll look in depth at Agile company cultures and how to create an environment where agility is possible.
  • You'll learn about the standard practices used in effective organizations, and more importantly, you'll learn why they work and how they interact with one another.
  • You'll learn how to integrate agility into your organization, how to transition to agile, and how to support agile effectively throughout the organization.

You'll come away from this class with a solid understanding of how to build a fully agile organization (and team) that actually works, and how to build software in fully agile way that's not tied into any one methodology.

Outline

  • The business case for Agile
  • Agility vs. Agile(tm)
  • Maximizing and accelerating return on investment
  • Small batches, rapid feedback loops.
  • Risk mitigation
  • Maximizing profit, eliminating waste
  • Budgeting and scope
  • Cost of delay
  • Agile contracts
  • The Agile Manifesto and Principles
  • The goal
  • The four guidelines
  • The 12 principles
  • How the principles translate to practice
  • Culture and the workplace
  • Cargo-cult agile
  • The physical workplace
  • Team structure
  • Hiring for learning, not tech.
  • The role of the coach/architect
  • The Drive culture: autonomy, mastery, purpose
  • Servant leadership
  • The role of "management"
  • Agile governance
  • The Spotify model
  • Tribes, squads, and guilds
  • The Spotify engineering culture
  • The Lean-Startup approach
  • Experiments and metrics
  • The pivot
  • Minimum viable product (MVP)
  • Transitioning to Agile
  • Changing the culture
  • Transition coaching
  • Lean manufacturing applied to software
  • Respect
  • Trust
  • Servant leadership
  • Give the stopwatch to the worker
  • The Theory of Constraints
  • Throughput and cycle time
  • Bottlenecks
  • Variability is additive
  • Pull
  • Mura, Muri, and Muda (variation, overwork, and waste)
  • Wait-time and slack
  • Quality and the Andon cord
  • Waste (TIM WOODS)
  • transport,
  • inventory,
  • motion,
  • waiting,
  • over-Processing,
  • overproduction,
  • defects and rework
  • (skills, underutilization)
  • Batch size and short cycles
  • Work-in-progress (WIP) limits
  • The coin game
  • Continuous improvement (Kaizen)
  • The retrospective
  • 5 whys
  • The Gemba walk and the on-site customer
  • Requirements gathering
  • Agile Kata, leveraging habitual behavior
  • Lean Accounting
  • Inventory
  • Planning
  • Estimates and #NoEstimates
  • Story-point planning
  • Stories
  • What is a story?
  • INVEST
  • MoSCoW
  • evolution
  • There's no such thing as a technical story
  • Narrow slices
  • Story maps and the backlog
  • Incremental design and development
  • Cumulative flow diagrams and projections
  • Practice
  • Tools and information radiators
  • Conway's Law
  • Inter-team cooperation
  • Version-control best practices
  • Mocks, Stubs, Simulators, and Emulators
  • Incremental development
  • Agile (stress-resistant) architecture
  • Microservices
  • Connecting stores to code
  • XP (Extreme Programming)
  • 5 Values
  • 4 Activities
  • 3 Principles
  • The on-site customer
  • Feedback Loops
  • Pair programming
  • Mob programming
  • The planning game
  • TDD (and Design by Coding)
  • Whole-team
  • Continuous integration
  • Merciless refactoring
  • Small releases
  • Coding standards
  • Collective ownership
  • simple design
  • System metaphor
  • Sustainable pace
  • Quality is not an option
  • test-first programming
  • integrated testing
  • Kanban
  • Continuous improvement
  • Continuous deployment
  • Pull models in software
  • Creating and using a kanban board
  • Layout
  • ticket design
  • WIP limits
  • Integrating Lean principles into software
  • Metrics
  • Flow
  • Cumulative Flow Diagrams
  • Throughput and Lead Time
  • Scrumban
  • Scrum (the good, the bad, and the ugly)
  • History
  • The Scrum Guide
  • Team
  • Product owner
  • Scrum master
  • Developer
  • Events
  • Sprint,
  • Planning,
  • Daily Scrum
  • Review,
  • Retrospective
  • Artifacts
  • Product Backlog
  • Sprint Backlog
  • Increment
  • Definition of Done
  • Where things usually go wrong
  • How can I miss the SM if he won't go away?
  • When the PO-model fails
  • where's the customer?
  • Sprint as a mini waterfall
  • Commitment vs. projections
  • Meeting culture
  • The SM is not a PM
  • QA not integrated
  • Story points
  • Scaling Agile
  • Dunbar's Number and W.L Gore
  • The problems with SAFe (and it's ilk)
  • The Agile PMO