Study Guide to Accelerate: Building and Scaling High Performing Technology Organizations
Study Guide to Accelerate: Building and Scaling High Performing Technology Organizations
by Dennis Britton
1. Move from Complicated to Simple
1.1. with Automation
1.2. with Policy
2. mainframes
3. Publication Details
3.1. Book Authors
3.1.1. Nicole Forsgren, PhD
3.1.2. Gene Kim
3.1.3. Jez Humble
3.2. Published by
3.2.1. IT Revolution
3.2.2. Portland, OR
4. influences and references
4.1. Origin and Influences
4.1.1. TOC
4.1.2. Lean
4.1.2.1. Kaizen
4.1.3. TPS
4.1.4. Kent Beck
4.1.4.1. Extreme Programming
4.1.5. Kanban
4.1.6. CI/CD
4.1.7. Craftsmanship Movement
4.1.7.1. Uncle Bob!
4.1.7.1.1. Robert R Martin
4.1.8. ITIL
4.1.9. Deming
4.1.9.1. PDCA
4.1.10. Gene Kim
4.1.11. Jez Humble
4.1.12. Martin Fowler
4.2. books
4.2.1. Accelerate
4.2.1.1. Scientific Study proving causation
4.2.1.2. Nicole Forsgren PHd, Gene Kim, Jez Humble
4.2.2. DevOps IT Handbook
4.2.2.1. Dev/Ops IT Handbook
4.2.3. The Phoenix Project
4.2.3.1. business novel showing crisis driven transition to dev/ops culture
4.2.3.1.1. includes appication of TOC
4.2.4. Mastery
4.2.4.1. George Leonard
4.2.4.2. On learning and High Peformance
4.2.5. Scaling Lean
4.2.5.1. Lean Startup at Scale
4.2.5.2. Ash Maury
4.2.6. Making Work Visible
4.2.6.1. Intro to Kanban
4.2.6.2. Domenica de Grandis
4.2.6.3. TFS Microsoft Project
4.2.7. Managing for Happiness
4.2.7.1. Jurgen Appelo
4.2.8. Creatiivity
4.2.8.1. Flow and the Psychology of Discovery and Invention
4.2.8.2. Mihaly Csikszentmihaly
4.2.8.2.1. pronounced 'Mee Hii'
5. Elements of high performance
5.1. Lean Product Development
5.1.1. Work in Small Batches
5.1.2. Make Flow fo Work Visual
5.1.3. Gather & Implement Customer Feedback
5.1.4. Foster Team Experimentation
5.2. Lean Management
5.2.1. Limit WIP
5.2.2. Visual Managment
5.2.3. Feedback from Production
5.2.4. LIghtweight Change Approvals
5.3. Engineering (enabling Continuous Delivery)
5.3.1. automation
5.3.2. trunk based development
5.3.3. shift left on security
5.3.3.1. build it into the overall sw dev process instead of at the end
5.3.4. looselly coupled architecture
5.3.4.1. enables scaling
5.3.5. empowered teams
5.3.5.1. allow teams to choose their tools
5.3.5.2. architects focus on engineers and their outcomes not tools/tech
5.3.6. Continuous Integration
5.3.7. Version Control
5.3.8. Test Data Management
5.3.9. Monitoring
5.3.10. Proactive Notifications
5.3.11. Extra Credit
5.3.11.1. Chaos Monkey
5.3.11.2. Self-Annealing Systems
5.3.11.3. AI
5.3.12. Focus On
5.3.12.1. Deployability
5.3.12.2. Testability
5.3.13. No Correlation to
5.3.13.1. Type of Systems
5.3.13.1.1. greenfield
5.3.13.1.2. systems of record
5.3.13.1.3. end user sw
5.3.13.1.4. off the shelf
5.3.13.1.5. custom
5.3.13.1.6. embedded
5.4. Measurement
5.4.1. of SW Delivery Performance
5.4.1.1. Deploy Frequency
5.4.1.2. Lead Time
5.4.1.2.1. Change Fail Percentage
5.4.1.3. Mean Time To Restore
5.5. Transformational Leadership (feeds all the rest)
5.5.1. Vision
5.5.2. Intellectual Stimulation
5.5.3. Inspirational Communication
5.5.4. Supportive Leadership
5.5.5. Personal Recognition
6. Benefits of High Perf Dev/Ops Company
6.1. 2X
6.1.1. profitability
6.1.2. productivity
6.1.3. market share
6.1.4. number of customers
6.1.5. qty of products and services
6.1.6. operating efficiency
6.1.7. customer satisfaction
6.1.8. quality of product/services
6.1.9. achieving org/mission goals
6.1.10. employee NPS
6.1.11. Team NPS
6.2. 50% higher market capitalization over 3 years than non-devops performers
6.3. Performance of High Peforming Dev/Ops Organizations
6.3.1. 46X more frequent code deployments
6.3.2. 440 times faster lead time from commit to deploy
6.3.3. 170 times faster mean time to recovery
6.3.4. 5 X lower change failure rate: 1/5 as likely for a change to fail
6.4. These times they are a changin'
6.4.1. "better information flow is critical to a safe and effective operation of high-tempo and high consequence environments"
6.4.2. OODA loop enables faster relevant response to change
6.4.2.1. Colonel Boyd
7. Starting the Evolution to High Performance
7.1. The Significance of Culture to High Performance
7.1.1. Pathological - Power Oriented
7.1.1.1. Traits
7.1.1.1.1. Bridging Discouraged
7.1.1.1.2. low cooperation
7.1.1.1.3. Messengers 'shot'
7.1.1.1.4. Responsibilities shirked
7.1.1.1.5. Failure leads to scapegoating
7.1.1.1.6. Novelty crushed
7.1.1.2. Effects
7.1.1.2.1. information transfer thwarted
7.1.1.2.2. communication distorted
7.1.1.2.3. decisions biased, not fact based
7.1.1.2.4. ability to learn from failure or even success is inhibited
7.1.2. Bureaucratic - Rule Oriented
7.1.2.1. traits
7.1.2.1.1. Narrow responsbilities
7.1.2.1.2. Bridging tolerated
7.1.2.1.3. Modest cooperation
7.1.2.1.4. Messengers neglected
7.1.2.1.5. Novelty leads to problems
7.1.2.1.6. Failure leads to justice
7.1.2.2. effects
7.1.2.2.1. following the rules is more important than achieving the mission
7.1.3. Generative - Performance Oriented
7.1.3.1. traits
7.1.3.1.1. Risks are shared
7.1.3.1.2. High cooperation
7.1.3.1.3. Messengers trained
7.1.3.1.4. Failure leads to inquiry
7.1.3.1.5. Novelty implemented
7.1.3.2. effects
7.1.3.2.1. more effective collaboration
7.1.3.2.2. mission is central, overcoming personal and departmental concerns
7.1.3.2.3. level playing field since status plays less of a role than effectiveness
7.1.4. Theory of High Performance Culture
7.1.4.1. organizations with better information flow function more effectively
7.1.4.1.1. What is 'better' information flow?
7.1.4.1.2. critical to a safe and effective operation of high-tempo and high consequence environments
7.1.4.2. since good culture require trust and collaboration across the organization this results in better decision making because better information is available
7.1.4.3. bad decisions are more easily reversed or adapted to because the team is more likely to be open and transparent rather than closed and hierarchical.
7.1.4.4. People will be less stressed, more happy and more engaged.
7.1.5. Theory of High Performance Software Delivery
7.2. Culture is key
7.3. "the way to change culture is not to first change how people think, but instead to start by changing how people behave—what they do"
7.3.1. on Toyota Nummi Plant rebirth
7.3.2. by John Shook
7.3.3. in 2010
7.4. Simply stated: Act your way to a performance culture!
7.5. A clarion call
7.5.1. a strongly expressed demand or request for action.
7.5.2. Again, if the trumpet does not sound a clear call, who will get ready for battle? 1 Cor 14:8
7.6. Learn Mastery
7.6.1. incremental training
7.6.2. make it possible
7.6.3. make it believable
7.6.4. push past the discomfort
7.6.5. read George Leonard
7.6.5.1. learning curve
7.6.5.1.1. plateau
7.6.5.1.2. early progress
7.6.5.1.3. shu ha ri
7.6.5.1.4. returning to help others
7.6.5.2. Aikido Sensei
7.6.5.3. Life magazine Photojournalist
8. What is Dev/Ops?
8.1. Continuous Delivery
8.1.1. Build Quality In
8.1.1.1. from W Edwards Deming
8.1.2. Work in Small Batches
8.1.2.1. user stories anyone?
8.1.2.2. TDD cycles of 30 seconds to 3 minute bewteen commits
8.1.3. Simplify and Automate Repetitive tasks
8.1.3.1. computers are better at this
8.1.3.2. isolate problem solving to humans
8.1.4. Relentlessly Pursue continuous Improvement
8.1.4.1. Kaizen!
8.1.4.2. Retrospective action items!
8.1.4.3. Iterations
8.1.5. Everyone is responsible
8.1.5.1. make system level outcomes transparent
8.1.5.2. Outcomes
8.1.5.2.1. measurable
8.1.5.2.2. achievable
8.1.5.2.3. timebound
8.1.6. foundations
8.1.6.1. comprehensive configuration management
8.1.6.1.1. version control
8.1.6.1.2. automated build/test/deploy
8.1.6.2. Continuous Integration