1. Systems thinking
1.1. Master complexity of dynamics instead of static details
1.2. Casual loop diagrams
1.2.1. Define variables such as # of defects, and link them them
1.2.2. Casual links
1.2.3. Delays
1.2.4. Quick fix reactions
1.2.5. Extreme effects
1.2.6. Constraints
1.2.7. Positive feedback loops
1.2.8. Opposite effect
1.3. Root cause tools
1.3.1. Ishikawa (Fishbone)
1.3.2. Five whys
1.3.3. Watch the baton, not the runners
1.4. Measurement dysfunction
1.5. Secret developer toolbox
2. Organisation redesign
2.1. How to transition into cross-functional?
2.1.1. Embed first: analysis, coding, soft.arch., testing
2.1.2. Gradually expand team responsibility
2.2. Cross-component, not component teams
2.2.1. Big, slow organisation will build big and slow systems
2.3. Self-management
2.3.1. Teams & individuals evolve their own practices and improvements
2.3.2. Need right environment first
2.3.3. Autonomous
2.3.4. Cross-functional / see the whole
2.3.5. Challenged
2.3.6. Manages the work & the work process
2.3.7. Yokoten - spread knowledge laterally
2.4. Avoid...projects in product development
2.5. Communities of Practice
2.5.1. Functional learning
2.5.2. Volountary
2.5.3. OpenSpace
2.6. Top-down and Bottom-up approach
2.7. Seeing the whole
2.7.1. Whole product
2.7.1.1. Product components as seen by the customer
2.7.2. Feature team co-creates product with users
2.7.3. Team specialisation in customer domain over technical
3. Lean
3.1. Reducing lean thinking to kanban, queue management and other tools is like reducing a working democracy to voting.
3.2. Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.
3.3. Principles
3.3.1. Kaizen
3.3.1.1. Culture of continuous improvement
3.3.1.1.1. Challenge status quo / everything
3.3.1.1.2. Why are we doing this?
3.3.1.1.3. Toyota "Global Goal"
3.3.1.1.4. "See the whole"
3.3.1.1.5. Genchi Genbutsu - Go and See
3.3.1.1.6. Stop and fix right
3.3.1.1.7. Improve for improvement's sake, endlessly
3.3.1.1.8. My work is to do my work and to improve my work
3.3.1.1.9. Yokoten - spread knowledge laterally
3.3.1.1.10. Waste
3.3.2. Respect
3.3.2.1. Management
3.3.2.1.1. Management commitment to continuously invest in its people
3.3.2.1.2. The responsibility lies, not with black belt specialists, but with the leadership hierarchy that runs the operation and they are teachers and coaches.
3.3.2.1.3. Act as teachers of thinking skills
3.3.2.1.4. Long term philosophy
3.3.2.1.5. "Transparency is the new control system"
3.3.2.2. Person at the next workstation is also your customer
3.4. Queueing Theory
3.4.1. Benefits
3.4.1.1. Reduced overall release-cycle-time
3.4.1.2. Freedom for business to ship a smaller product earlier
3.4.1.3. Ineffective practices are exposed
3.4.2. WIP queue
3.4.3. Shared resource queue
3.4.4. Invisible queue
3.4.5. Serial vs parallel development
3.4.5.1. Point kaizen (kanban system)
3.4.5.2. System kaizen
3.4.5.2.1. Eradicate a queue
3.4.6. Scrum: queue of feature requests in PBL
3.4.7. Suggestions in Scrum
3.4.7.1. Similar-sized user stories in release backlog
3.4.7.2. Product Backlog Refinement workshop - 5%
3.4.7.3. Stable feature teams
3.4.7.4. Spike - timeboxed effort-boxed learning goal
3.4.8. Theory of Constrains (TOC)
3.4.8.1. One bottleneck that limits throughput
4. Re-use info and knowledge
4.1. Wiki
4.2. Design Patterns
5. Team
5.1. Advantages
5.1.1. Deliver what customer values most
5.1.2. Intensified learning
5.1.3. Planning is easier
5.1.4. Handoff reduced
5.1.5. Less waiting waste
5.1.6. Cost reduction, efficiency, less management
5.2. Team as org. building block
5.2.1. Accountability
5.2.2. Leadership changes in team
5.2.3. Across all disciplines
5.2.4. 7 +- 2 people
5.2.5. Cross-component
5.2.6. Balance
5.2.7. Long-lived
5.2.8. Identity
5.2.9. Empowerment
5.2.10. Generalising specialists
5.2.11. Consensus
5.2.12. Working agreements
5.2.13. Cross-functional
5.2.14. Co-located
5.2.15. Could work on multiple products
5.2.16. Shared responsibility
6. Architecture and design
6.1. Set-based design (exploring several alternatives)
6.2. Design workshop
6.3. Agile Modelling
7. Writing code
7.1. No locking in version control
7.2. Continuous Integration
7.3. Trunk based development
7.3.1. Avoid...Staircase branching
7.4. TDD
7.5. Evolutionary Design
7.6. Shared code ownership
7.6.1. Component guardians
7.6.2. Architecture code police
7.6.3. Community of practice
7.6.4. Part-time architectural community of practice
7.6.5. Temporary infrastructure team
8. Multiple teams
8.1. Working agreements
8.1.1. Definition of Done
8.2. Requirements area
8.2.1. Customer centric
8.2.2. Set of strongly related features
8.2.3. Independently managed area backlog
9. Tools
9.1. Avoid traditional requirement management tools
9.2. Avoid tools optimized for reporting
9.2.1. Prevents Genchi Genbutsu
10. Scrum Scaled Up
10.1. LeSS basic
10.1.1. Up to 8 teams
10.1.2. Domain experts can help PO
10.1.3. Refinement can be done by teams
10.1.4. PO not involved in low level details
10.1.5. Sprint planning part 1
10.1.5.1. All teams in one room
10.1.5.2. or 2 representatives from each team
10.1.5.3. Teams volunteer backlog items
10.1.6. Daily Scrum
10.1.6.1. members from other teams observe as chickens
10.1.7. Joint retrospective
10.2. LeSS huge
10.2.1. Requirement areas (if more than 8 teams)
10.2.1.1. Area backlog
10.2.1.2. Area Product Owner
10.2.1.3. Dedicated Scrum Feature teams
10.2.2. Product Owner team
10.2.2.1. PO and all APOs
10.3. LeSS ScrumMaster
10.3.1. Deals with large-scale problems
10.3.2. Focus in later stage
10.3.2.1. Change organisation
10.3.2.2. Development practices
10.3.3. Focus in beginning
10.3.3.1. Product Owner
10.3.3.2. Team
10.3.4. Colocate with teams
10.4. Product Owner in LeSS
10.4.1. Candidates
10.4.1.1. Product manager
10.4.1.2. Someone from user group with authority
10.4.1.3. From company receiving the system, close to user
10.5. Timeboxing
10.5.1. Takt time
10.5.2. Enforces cadence
10.5.3. Increases focus
10.5.4. Limits scope creep
10.5.5. Limits gold-plating
10.5.6. Reduces Student Syndrome