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. Re-use info and knowledge
2.1. Wiki
2.2. Design Patterns
3. Team
3.1. Advantages
3.1.1. Deliver what customer values most
3.1.2. Intensified learning
3.1.3. Planning is easier
3.1.4. Handoff reduced
3.1.5. Less waiting waste
3.1.6. Cost reduction, efficiency, less management
3.2. Team as org. building block
3.2.1. Accountability
3.2.2. Leadership changes in team
3.2.3. Across all disciplines
3.2.4. 7 +- 2 people
3.2.5. Cross-component
3.2.6. Balance
3.2.7. Long-lived
3.2.8. Identity
3.2.9. Empowerment
3.2.10. Generalising specialists
3.2.11. Consensus
3.2.12. Working agreements
3.2.13. Cross-functional
3.2.14. Co-located
3.2.15. Could work on multiple products
3.2.16. Shared responsibility
4. Architecture and design
4.1. Set-based design (exploring several alternatives)
4.2. Design workshop
4.3. Agile Modelling
5. Writing code
5.1. No locking in version control
5.2. Continuous Integration
5.3. Trunk based development
5.3.1. Avoid...Staircase branching
5.4. TDD
5.5. Evolutionary Design
5.6. Shared code ownership
5.6.1. Component guardians
5.6.2. Architecture code police
5.6.3. Community of practice
5.6.4. Part-time architectural community of practice
5.6.5. Temporary infrastructure team
6. Multiple teams
6.1. Working agreements
6.1.1. Definition of Done
6.2. Requirements area
6.2.1. Customer centric
6.2.2. Set of strongly related features
6.2.3. Independently managed area backlog
7. Tools
7.1. Avoid traditional requirement management tools
7.2. Avoid tools optimized for reporting
7.2.1. Prevents Genchi Genbutsu
8. Multisite
8.1. Colocate entire requirement area? Yes and No!
9. Type of development
9.1. Product (external customer)
9.2. Internal (IT department)
9.3. Project (outsourcer)
10. Organisation redesign
10.1. How to transition into cross-functional?
10.1.1. Embed first: analysis, coding, soft.arch., testing
10.1.2. Gradually expand team responsibility
10.2. Cross-component, not component teams
10.2.1. Big, slow organisation will build big and slow systems
10.3. Self-management
10.3.1. Teams & individuals evolve their own practices and improvements
10.3.2. Need right environment first
10.3.3. Autonomous
10.3.4. Cross-functional / see the whole
10.3.5. Challenged
10.3.6. Manages the work & the work process
10.3.7. Yokoten - spread knowledge laterally
10.4. Avoid...projects in product development
10.5. Communities of Practice
10.5.1. Functional learning
10.5.2. Volountary
10.5.3. OpenSpace
10.6. Top-down and Bottom-up approach
10.7. Seeing the whole
10.7.1. Whole product
10.7.1.1. Product components as seen by the customer
10.7.2. Feature team co-creates product with users
10.7.3. Team specialisation in customer domain over technical
11. Lean
11.1. Reducing lean thinking to kanban, queue management and other tools is like reducing a working democracy to voting.
11.2. Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.
11.3. Principles
11.3.1. Kaizen
11.3.1.1. Culture of continuous improvement
11.3.1.1.1. Challenge status quo / everything
11.3.1.1.2. Why are we doing this?
11.3.1.1.3. Toyota "Global Goal"
11.3.1.1.4. "See the whole"
11.3.1.1.5. Genchi Genbutsu - Go and See
11.3.1.1.6. Stop and fix right
11.3.1.1.7. Improve for improvement's sake, endlessly
11.3.1.1.8. My work is to do my work and to improve my work
11.3.1.1.9. Yokoten - spread knowledge laterally
11.3.1.1.10. Waste
11.3.2. Respect
11.3.2.1. Management
11.3.2.1.1. Management commitment to continuously invest in its people
11.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.
11.3.2.1.3. Act as teachers of thinking skills
11.3.2.1.4. Long term philosophy
11.3.2.1.5. "Transparency is the new control system"
11.3.2.2. Person at the next workstation is also your customer
11.4. Queueing Theory
11.4.1. Benefits
11.4.1.1. Reduced overall release-cycle-time
11.4.1.2. Freedom for business to ship a smaller product earlier
11.4.1.3. Ineffective practices are exposed
11.4.2. WIP queue
11.4.3. Shared resource queue
11.4.4. Invisible queue
11.4.5. Serial vs parallel development
11.4.5.1. Point kaizen (kanban system)
11.4.5.2. System kaizen
11.4.5.2.1. Eradicate a queue
11.4.6. Scrum: queue of feature requests in PBL
11.4.7. Suggestions in Scrum
11.4.7.1. Similar-sized user stories in release backlog
11.4.7.2. Product Backlog Refinement workshop - 5%
11.4.7.3. Stable feature teams
11.4.7.4. Spike - timeboxed effort-boxed learning goal
11.4.8. Theory of Constrains (TOC)
11.4.8.1. One bottleneck that limits throughput
12. Scrum Scaled Up
12.1. LeSS basic
12.1.1. Up to 8 teams
12.1.2. Domain experts can help PO
12.1.3. Refinement can be done by teams
12.1.4. PO not involved in low level details
12.1.5. Sprint planning part 1
12.1.5.1. All teams in one room
12.1.5.2. or 2 representatives from each team
12.1.5.3. Teams volunteer backlog items
12.1.6. Daily Scrum
12.1.6.1. members from other teams observe as chickens
12.1.7. Joint retrospective
12.2. LeSS huge
12.2.1. Requirement areas (if more than 8 teams)
12.2.1.1. Area backlog
12.2.1.2. Area Product Owner
12.2.1.3. Dedicated Scrum Feature teams
12.2.2. Product Owner team
12.2.2.1. PO and all APOs
12.3. LeSS ScrumMaster
12.3.1. Deals with large-scale problems
12.3.2. Focus in later stage
12.3.2.1. Change organisation
12.3.2.2. Development practices
12.3.3. Focus in beginning
12.3.3.1. Product Owner
12.3.3.2. Team
12.3.4. Colocate with teams
12.4. Product Owner in LeSS
12.4.1. Candidates
12.4.1.1. Product manager
12.4.1.2. Someone from user group with authority
12.4.1.3. From company receiving the system, close to user
12.5. Timeboxing
12.5.1. Takt time
12.5.2. Enforces cadence
12.5.3. Increases focus
12.5.4. Limits scope creep
12.5.5. Limits gold-plating
12.5.6. Reduces Student Syndrome