1. Domain 1: Agile Principles and Mindsets
1.1. Why Use Agile?
1.1.1. Knowledge Work Projects Are Different
1.1.2. Defined versus Empirical Processes
1.2. The Agile Mindset
1.2.1. Personal, Team, and Organizational Agility
1.2.1.1. Declaration of Interdependence (DOI)
1.2.1.2. Difference between “being agile” and “doing agile”
1.2.1.3. Creating organizational change: Think-Do-Encourage others
1.2.2. The Agile Triangle
1.2.2.1. Inverted Triangle Model: Cost, Time (fixed), Scope (variable)
1.2.2.2. We aim to deliver the most value we can by X date within X budget
1.3. The Agile Manifesto
1.3.1. The Four Values
1.3.1.1. Individuals and interactions over processes and tools
1.3.1.2. Working software over comprehensive documentation
1.3.1.3. Customer collaboration over contract negotiation
1.3.1.4. Responding to change over following a plan
1.3.2. The Twelve Principles
1.3.2.1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
1.3.2.2. Welcome changing requirements, even late indevelopment. Agile processes harness change forthe customer's competitive advantage.
1.3.2.3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
1.3.2.4. Business people and developers must worktogether daily throughout the project.
1.3.2.5. Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.
1.3.2.6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
1.3.2.7. Working software is the primary measure of progress.
1.3.2.8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
1.3.2.9. Continuous attention to technical excellence and good design enhances agility.
1.3.2.10. Simplicity – the art of maximizing the amount of work not done – is essential.
1.3.2.11. The best architectures, requirements, and designs emerge from self-organizing teams.
1.3.2.12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
1.4. Agile Methodologies
1.4.1. Scrum
1.4.1.1. Scrum Pillars and Values
1.4.1.1.1. 3 Pillars
1.4.1.1.2. 5 Fundamental Values
1.4.1.2. Sprints
1.4.1.2.1. Time boxed iteration
1.4.1.3. Scrum Team Roles
1.4.1.3.1. Development Team
1.4.1.3.2. Product Owner
1.4.1.3.3. ScrumMaster
1.4.1.4. Scrum Activities (Events, Ceremonies)
1.4.1.4.1. Product Backlog Refinement
1.4.1.4.2. Sprint Planning Meetings
1.4.1.4.3. Daily Scrums
1.4.1.4.4. Sprint Reviews
1.4.1.4.5. Sprint Retrospectives
1.4.1.5. Scrum Artifacts
1.4.1.5.1. Product Increment
1.4.1.5.2. Product Backlog
1.4.1.5.3. Sprint Backlog
1.4.2. Extreme Programming (XP)
1.4.2.1. XP Core Values
1.4.2.1.1. Simplicity
1.4.2.1.2. Communication
1.4.2.1.3. Feedback
1.4.2.1.4. Courage
1.4.2.1.5. Respect
1.4.2.2. XP Team Roles
1.4.2.2.1. Coach
1.4.2.2.2. Customer
1.4.2.2.3. Programmer
1.4.2.2.4. Tester
1.4.2.3. XP Core Practices
1.4.2.3.1. Whole Team
1.4.2.3.2. Planning Games
1.4.2.3.3. Small Releases
1.4.2.3.4. Customer Tests
1.4.2.3.5. Collective Code Ownership
1.4.2.3.6. Code Standard
1.4.2.3.7. Sustainable Pace
1.4.2.3.8. Metaphor
1.4.2.3.9. Continuous integration
1.4.2.3.10. Test-Driven Development
1.4.2.3.11. Refactoring
1.4.2.3.12. Simple Design
1.4.2.3.13. Pair Programming
1.4.3. Lean Product Development
1.4.3.1. High-level Principles
1.4.3.1.1. Using visual management tools
1.4.3.1.2. Identifying customer-defined value
1.4.3.1.3. Building in learning and continuous improvement
1.4.3.2. Lean Core Concepts
1.4.3.2.1. Eliminate waste
1.4.3.2.2. Empower the team
1.4.3.2.3. Deliver fast
1.4.3.2.4. Optimize the whole
1.4.3.2.5. Build quality in
1.4.3.2.6. Defer decisions
1.4.3.2.7. Amplify learning
1.4.3.3. The Seven Wastes of Lean (muda)
1.4.3.3.1. Partially done work
1.4.3.3.2. Extra processes
1.4.3.3.3. Extra features
1.4.3.3.4. Task switching
1.4.3.3.5. Waiting
1.4.3.3.6. Motion
1.4.3.3.7. Defects
1.4.4. Kanban
1.4.4.1. Five Principles of Kanban
1.4.4.1.1. Visualize the workflow
1.4.4.1.2. Limit WIP
1.4.4.1.3. Manage flow
1.4.4.1.4. Make process politics explicit
1.4.4.1.5. Improve collaboratively
1.4.4.2. Kanban’s Pull System
1.4.4.3. WIP Limits in Kanban
1.4.5. Feature-Driven Development (FDD)
1.4.6. Dynamic Systems Development Method (DSDM)
1.4.6.1. 8 Principles; created before the Agile manifesto was written, they are closely aligned to the Manifesto
1.4.6.1.1. Focus on business need
1.4.6.1.2. Deliver on time
1.4.6.1.3. Collaborate
1.4.6.1.4. Never compromise quuality
1.4.6.1.5. Build incrementally from firm foundations
1.4.6.1.6. Develop iteratively
1.4.6.1.7. Communicate continuously and clearly
1.4.6.1.8. Demonstrate control
1.4.7. Crystal
1.5. Agile Process Overview
1.6. Agile Leadership
1.6.1. Management versus Leadership
1.6.1.1. Management Focus
1.6.1.1.1. Tasks/Things
1.6.1.1.2. Control
1.6.1.1.3. Efficiency
1.6.1.1.4. Dong things right
1.6.1.1.5. Speed
1.6.1.1.6. Practices
1.6.1.1.7. Command
1.6.1.2. Leadership Focus
1.6.1.2.1. People
1.6.1.2.2. Empowerment
1.6.1.2.3. Effectiveness
1.6.1.2.4. Doing the right things
1.6.1.2.5. Direction
1.6.1.2.6. Principles
1.6.1.2.7. Communication
1.6.2. Servant Leadership
1.6.2.1. Shield the team from interruptions
1.6.2.2. Remove impediments to progress
1.6.2.2.1. Obstacles
1.6.2.2.2. Impediment backlogs
1.6.2.3. Communicate (re-communicate) the project vision
1.6.2.3.1. Servant leaders need to continually look for opportunities to communicate the project vision and find new ways to illustrate and reinforce that vision
1.6.2.4. Carry food and water
1.6.2.4.1. providing the essential resources a team needs to keep them nourished and productive
1.6.2.4.2. Leaders also need to celebrate victories
1.6.2.4.3. Training and other professional development activities
1.6.3. Twelve Principles for Leading Agile Projects
1.6.3.1. Learn the team members’ needs
1.6.3.2. Learn the project’s requirements
1.6.3.3. Act for the simultaneous welfare of the team and the project
1.6.3.4. Create an environment of functional accountability
1.6.3.5. Have a vision of the completed project
1.6.3.6. Use the project vision to drive your own behavior
1.6.3.7. Serve as the central figure in successful project team development
1.6.3.8. Recognize team conflict as a positive step
1.6.3.9. Manage with an eye towards ethics
1.6.3.10. Remember that ethics is not an afterthought, but an integral part of our thinking
1.6.3.11. Take time to reflect on the project
1.6.3.12. Develop the trick of thinking backwards
1.6.4. Agile Leadership Practices
1.6.4.1. Leading by example
1.6.4.2. Model Desired Behavior
1.6.4.2.1. Honesty
1.6.4.2.2. Forward-looking
1.6.4.2.3. Competent
1.6.4.2.4. Inspiring
1.6.4.3. Communicate the Project Vision
1.6.4.4. Enable Others to Act
1.6.4.5. Be Willing to Challenge the Status Quo
1.6.5. Leadership Tasks
1.6.5.1. Practice Transparency through Visualization
1.6.5.2. Create a Safe Environment for Experimentation
1.6.5.3. Experiment with New Techniques and Processes
1.6.5.4. Share Knowledge through Collaboration
1.6.5.5. Encourage Emergent Leadership via a Safe Environment
2. Domain 2: Value-Driven Delivery
2.1. Assessing Value
2.1.1. What is Value-Driven Delivery?
2.1.1.1. Agile Value Proposition
2.1.1.1.1. Business Value
2.1.1.1.2. Risk
2.1.1.1.3. Visibility
2.1.1.1.4. Adaptability
2.1.1.2. Deliver Value Early (Eat Your Desert First)
2.1.1.3. Minimize Waste
2.1.2. Financial Assessment Metrics
2.1.2.1. Return on Investment (ROI)
2.1.2.2. Net Present Value (NPV)
2.1.2.3. Internal Rate of Return (IRR)
2.1.2.4. Earned Value Management (EVM)*
2.1.2.4.1. S-Curve Graph
2.1.2.4.2. Gantt Chart
2.1.2.4.3. Constructing an Agile Earned Value Tool
2.1.2.5. Agile Project Accounting
2.1.2.6. Key Performance Indicators (KPIs)
2.1.2.6.1. Rate of progress
2.1.2.6.2. Remaining work
2.1.2.6.3. Likely completion date
2.1.2.6.4. Likely cost remaining
2.1.2.7. Managing Risk
2.1.2.7.1. “anti-value”
2.1.2.7.2. PMBOK Guide - Chapter 11.1.
2.1.2.7.3. Regulatory Compliance
2.1.3. Earned Value Early (Eat Your Dessert First!)
2.1.4. Minimize Waste
2.2. Prioritizing Value
2.2.1. Customer-Valued Prioritization
2.2.1.1. Scrum: Product Backlog
2.2.1.2. FDD: Feature List
2.2.1.3. DSDM: Prioritized Requirements List
2.2.2. Prioritization Schemes
2.2.2.1. Simple Schemes
2.2.2.1.1. High
2.2.2.1.2. Medium
2.2.2.1.3. Low
2.2.2.2. MoSCow
2.2.2.2.1. Must have
2.2.2.2.2. Should have
2.2.2.2.3. Could have
2.2.2.2.4. Would like to have, but not this time
2.2.2.3. Monopoly Money
2.2.2.3.1. “Buy a feature”
2.2.2.4. 100-Point Method
2.2.2.5. Dot Voting or Multi-Voting
2.2.2.6. Kano Analysis
2.2.2.6.1. Delighter/exciters
2.2.2.6.2. Satisfiers
2.2.2.6.3. Dissatisfiers
2.2.2.6.4. Indifferent
2.2.2.7. Requirements Prioritization Model
2.2.2.7.1. Karl Wiegers
2.2.2.7.2. based on value, cost, risk
2.2.3. Relative Prioritization/Ranking
2.3. Delivering Incrementally
2.3.1. Minimal Viable Product (MVP)
2.3.2. Agile Tooling
2.3.3. Low-Tech, High Tech Tools
2.3.4. Task/Kanban Boards
2.3.5. Work in Progress (WIP)
2.3.6. WIP Limits
2.3.7. Cumulative Flow Diagrams (CFDs)
2.3.8. Bottleneck and the Theory of Constraints
2.4. Agile Contracting
2.4.1. Agile Constraints and Contracts
2.4.2. DSDM Contact
2.4.3. Money for Nothing and Change for Free
2.4.4. Graduated Fixed-Price Contract
2.4.5. Fixed-Price Work Packages
2.4.6. Customized Contracts
2.5. Verifying and Validating Value
2.5.1. Frequent Verification and Validation
2.5.2. Testing and Verification in Software Development
3. Domain 3: Stakeholder Engagement
3.1. Taking Care of the Stakeholders
3.1.1. Stakeholder Stewardship versus Stakeholder Management
3.1.2. Educating Stakeholders about Agile
3.1.3. Keeping Stakeholders Engaged
3.1.4. Why the Big Focus on Stakeholders?
3.1.5. Principles of Stakeholder Engagement
3.2. Establishing a Shared Vision
3.2.1. Agile Chartering
3.2.2. Definition of “Done”
3.2.2.1. User Stories
3.2.2.1.1. Developed
3.2.2.1.2. Documented
3.2.2.1.3. User acceptance tested
3.2.2.2. Releases
3.2.2.2.1. Alpha System is replaced and there are no P1 incidents or change requests
3.2.2.3. Final project deliverables
3.2.2.3.1. high- and medium features are implemented, there are two month of trouble-free operations, and the project receives satisfaction scores greater than 70 percent from the user community
3.2.3. Agile Modeling
3.2.4. Wireframes
3.2.5. Personas
3.3. Communicating with Stakeholders
3.3.1. Face-to-Face Communication
3.3.2. Two-Way Communication
3.3.3. Knowledge Sharing
3.3.4. Information Radiators
3.3.5. Social Media
3.4. Working Collaboratively
3.4.1. Workshops
3.4.2. Brainstorming
3.4.3. Collaboration Games
3.5. Using Critical Interpersonal Skills
3.5.1. Emotional Intelligence
3.5.2. Active Listening
3.5.3. Facilitation
3.5.4. Negotiation
3.5.5. Conflict Resolution
3.5.6. Participatory Decision Making
4. Domain 4: Team Performance
4.1. Building Agile Teams
4.1.1. Benefits of Generalizing Specialists
4.1.2. Characteristics of High-Performing Teams
4.1.3. Models of Team Development
4.1.4. Adaptive Leadership
4.1.5. Team Motivation
4.1.6. Training, Coaching, and Mentoring
4.2. Creating Collaborative Team Spaces
4.2.1. Co-Located Teams
4.2.2. Osmotic Communication
4.2.3. Global, Cultural, and Team Diversity
4.2.4. Distributed Teams
4.3. Tracking Team Performance
4.3.1. Burn Charts
4.3.2. Velocity
5. Domain 5: Adaptive Planning
5.1. Agile Planning Concepts
5.1.1. Adaptive Planning
5.1.2. Agile versus Non-Agile Planning
5.1.3. Principles of Agile Planning
5.1.4. Agile Discovery
5.1.5. Value-Based Analysis
5.1.6. Value-Based Decomposition
5.1.7. Timeboxing
5.1.8. Estimate Ranges
5.1.9. Ideal Time
5.2. Tools for Sizing and Estimating
5.2.1. Sizing, Estimating, and Planning
5.2.2. Decomposition Requirements
5.2.3. User Stories
5.2.4. User Story Backlog (Product Backlog)
5.2.5. Refining (Grooming) the Backlog
5.2.6. relative Sizing and Story Points
5.2.7. Affinity Estimating
5.2.8. T-Shirt Sizing
5.2.9. Story Maps
5.2.10. Product Roadmap
5.2.11. Wideband Delphi
5.2.12. Planning Poker
5.3. Release and Iteration Planning
5.3.1. Types of Iterations
5.3.2. Spikes
5.3.3. High-Level Planning (Visioning)
5.3.4. Release Planing
5.3.5. Iteration Planning
5.3.6. Daily Stand-Ups
6. Domain 6: Problem Detection and Resolution
6.1. Understanding Problems
6.1.1. How Problems Impact a Project
6.1.2. The Cost of Change
6.1.3. Technical Dept
6.1.4. Create a Safe and open Environment
6.1.5. Failure Models
6.1.6. Success Models
6.1.7. Success Strategies
6.2. Detecting Problems
6.2.1. Lead Time and Cycle Time
6.2.2. Defects
6.2.3. Variance Analysis
6.2.4. Trend Analysis
6.2.5. Control Limits
6.3. Managing Threats and Issues
6.3.1. Risk-Adjusted Backlog
6.3.2. Risk Severity
6.3.3. Risk Burndown Graphs
6.4. Solving Problems
6.4.1. Problem Solving as Continuous Improvement
6.4.2. Engage the Team
6.4.3. Some Problems Can’t Be Solved
7. Domain 7: Continuous Improvement
7.1. Continuous Improvement - Process
7.1.1. Process Tailoring
7.1.2. Systems Thinking
7.1.3. Process Analysis
7.1.4. Value Stream Mapping
7.1.5. Project Pre-Mortems
7.2. Continuous Improvement - Product
7.2.1. Reviews
7.2.2. Product Feedback Loops and Learning Cycles
7.2.3. Feedback Methods
7.2.4. Approved Iterations
7.3. Continuous Improvement - People
7.3.1. Retrospectives
7.3.2. Team Self-Assessments