Review

There’s no shortage of books putting forward an opinion about how to build digital products - few though are evidence based. The authors behind Accelerate have based their findings on research and data. As such, this is book has become incredibly influential in product and engineering circles.

This is a must read. The book provides an introduction to DevOps but it’s also one of the best books on building high performing teams. It’s now best practice across the industry to track the DORA metrics. There’s very little cultural advice in this book I disagree with.

You Might Also Like…

Team Topologies

This book is essential reading if you need or want to learn a little more about organisational design. The model in this book is a simplification of a messier reality, but it’s a useful frame of reference. It establishes a limited number of team types and interaction types between teams. The authors then explain how fracture planes and sensing/triggers can help you identify the best team topologies.

andrewclark.co.uk

Project to Product

I'm not sure if the 'Flow Framework' is the golden goose of transformation. I found the theory intriguing, but I have reservations about implementing it within a large organisation. There was a lack of practical implementation advice, and based on my experience, I believe it would be challenging to implement without a team of consultants. Nevertheless, there are plenty of interesting nuggets and principles in this book. It has certainly influenced my perspective on team topologies, and managing those zero-sum tradeoffs between features, quality and risk.

andrewclark.co.uk

Book Review and Summary: The Mythical Man Month by Fred Brooks

Get a comprehensive review and summary of the classic book "The Mythical Man Month" by Fred Brooks, the software engineering and management expert. Learn about the key principles and practices for managing software development projects and teams effectively.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

• Companies should look to measure and improve capabilities and avoid 'maturity models'
• The authors research links software development performance to organisational performance.
• Adopt Dev-Ops best practice and you can dramatically increase frequency of deployments, reliability, recovery time and speed from keyboard to production.
• Studies have shown you don't have to trade speed for quality, you can have both.
• Avoid measuring and rewarding developers for throughput and operations for stability - as it’s going to end in tears.
• Successful measures need to focus on global outcomes (not local, not output).

• Introducing the DORA metrics - every team should be measuring these
• Deployment Frequency (Tempo)
• Using deployment lead time as a proxy for batch size. Reducing batch size reduces cycle time, flow variability, accelerates feedback, reduces risk, improves efficiency, increases motivation and reduces cost.
• How often do you deploy to production or to the app store?
• Options: OnDemand, hourly, daily, weekly, monthly, 6 monthly, fewer
• Lead time for Changes (Tempo)
• Shorter is better. Faster feedback, quicker course correction. Better in an outage.
• Two important periods, but only one is measured. Time to design and validate (hard to know when to start the clock). Time to build and deliver (easier to measure).
• Time from code committed to code deployed?
• Options: less than 1 hour, 1 day, 1 week, 1 month, 6 months, longer
• Mean time to Recovery (Stability)
• Failure is inevitable, so we ask how quickly can service be restored.
• How long does it take to restore service when there's an unplanned outage.
• Options: less than 1 hour, 1 day, 1 week, 1 month, 6 months, longer
• Change Failure Rate (Stability)
• What % of changes to production fail? Including infrastructure and configuration changes result in degraded service or require remediation?

• There is no tradeoff between speed and quality. High performers do better at all the measures.
• Software performance is a good predictor of company performance (profit, market share and productivity). Hitting goals, customer satisfaction etc.
• Companies should distinguish which technology is strategic and which isn't, and acquire non-strategic services as SaaS)
• Culture is important, but people think it's intangible and hard to measure.
• Organisational culture predicts the way that information flows through the organisation.
• Good information flow : provides answers, is timely, presented in a way it can be effectively used.
• Better information flow better performance.
1. Trust and cooperation between people across the organisation
2. Better organisational higher quality decision making
3. Likely to do a better job with people, problems are rapidly discovered and addressed
• Google found that team dynamics are more important than the individuals within a team.
• How failure is dealt with is a good measure. You need psychological safety.

• Continuous delivery is a set of capabilities that allow us to get changes into production safely quickly and reliably
• Key Principles of Continuous Delivery
1. Build Quality In (so less pressure on testing)
2. Detect issues quickly, so they’re cheap and easy to resolve
3. Work in small batches
4. Computers perform repetitive work tasks, people solve problems
5. Continuous improvement
6. Everyone is responsible (system level outcomes)
• To implement continuous delivery you need
• comprehensive configuration management - fully automated version control
• continuous integration
• continuous testing - all the way through building
• Impact of continuous delivery
• decrease deployment pain and employee burnout
• identify more strongly with the organisation that they work for
• higher levels of software delivery performance
• helps with sustainable development
• save time on rework (bugs and patches) {as a proxy of quality}

• Reduce dependencies across teams
• Architecture should map to teams
• Tool choice - let teams choose their own tools
• Focus on engineers and outcomes - not tools and technologies
• Design things so they have freedom

• Build security into software development. Shift left with security - review features as soon as possible - Security should be involved in design.
• Rugged movement - refuse to be vulnerable - choose to be rugged - being rugged is everyone’s responsibility

• Lean Management Practices
• Removing work in progress
• Making metrics and dashboards visible (to engineers and leaders) - ease of access is key
• Use these tools to make decisions on a daily basis
• Approval by an external body slows things down and doesn’t improve reliability
• Segregation of duties + peer review + auditable pipeline = is great

• Companies still: spend too long on requirements, budgeting, large releases and customer feedback seems to be an afterthought
• Companies should: test products design and business model by frequent user testing
• Lean Startup: Experimental approach to product development. Lean and design thinking. Pivot early and often,
• Take an experimental approach
• Lean Product Development Capabilities
• Small releases. 1 week max. MVP
• Flow of work from business to customers. Make it visible to everyone.
• Actively and regularly seek customer feedback + incorporate it into products
• Development team have authority to change specifications as part of the process without approval
• Software performance predicts lean product development practices. Virtuous cycle.
• Working in small batches. Making rapid development possible. Short lead times, and faster feedback loops. A/B testing.
• Team Experimentation: Seek input from customers throughout the process. Ability of teams to try out new ideas without approval is important.

• What to do to decrease burnout:
• Blame free environment
• Make deployments painless
• Effectiveness of leaders
• Investment in Dev ops
• Support experimentation and learning
• Give people some time to work on new and exciting projects
• Align organisational values with individuals values

• Hire, retain and delight
• Employee NPS - Higher NPS have higher retention
• Diversity matters - smarter, better team performance and business outcomes
• Inclusion must be present for diversity to take hold

• Leadership is about inspiring and motivating those around you
• Transformation Leader Characteristics
• Vision
• Inspirational communication
• Intellectual stimulation
• Supportive leadership
• Personal recognition
• Transformational leadership - inspire, empower, develop, identify, engage, align
• Statistically significance and highly correlated with NPS
• Enabling practices - continuous experimentation and learning
• Culture
• Climate of learning - space to explore ideas
• Safe to fail
• Space to share knowledge
• Let them choose their tools
• Make monitoring a priority

• Organisational Transformation
• Priorities and objectives visualised - as it progress
• Problems remain visualised until they are solved
• Matrix structure - value streams - squads - squads have product owners, are cross functional, follow the 2 pizza rule (biz dev ops)
• WIP is visualised
• Stand-ups but less meetings overall
• Let people own quality - let them not release if they’re not comfortable
• Standard ways of working save time and energy
• How do we learn how to learn?
• Coaches question assumptions and challenge behaviours
• Do it in cycles, the it becomes routine
• Get people to share how they work
• Develop and maintain the right mindset
• Do things on your own - Don’t contract out to a consulting firm to transform your organisation
• Demonstrate behaviours don’t delegate them

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Part One: What we found

1) Accelerate

• Technology is transforming industries, and becoming more important to organisations.
• Technology is unlocking a new level of service.
• Boards are pressuring executives to digitally transform.
• Executives think they're further along the transformation journey than those on the ground, highlighting the need for better measurement.
• Companies should look to measure and improve capabilities and avoid 'maturity models'
• Maturity models imply you can finish, when the most innovative firms strive for continuous improvement and never declare their work done.
• Maturity models are rigid, whereas teams can choose which capabilities will be most impactful to their outcomes.
• Maturity models are static, and don't take into account the shifting technology and business landscape.
• The authors research links software development performance to organisational performance.
• There are 24 capabilities that make a difference, they're easy to define, measure and improve.
• Surprisingly, some things didn’t influence outcomes: age of technology, who deploys code and having change approval boards.
• Adopt Dev-Ops best practice and you can dramatically increase frequency of deployments, reliability, recovery time and speed from keyboard to production.
• Studies have shown you don't have to trade speed for quality, you can have both.

2) Measuring Performance

• There are many frameworks and methodologies that aim to improve how we build software and services. We wanted to discover what works and what doesn't.
• Identify the best metrics for software delivery and performance.
• Approaches:
• Productivity based: focuses on outputs not outcomes. Focus on team measures not global ones.
• Lines of code: Less is better than more, until it becomes hard to understand.
• Velocity (points): Team dependent, if measured increase sizes
• Utilisation: high utilisation is good to a point
• Avoid rewarding developers for throughput and operations for stability - as it’s going to end in tears.
• Successful measures need to focus on global outcomes (not local, not output).
• Introducing the DORA metrics - every team should be measuring these
• DORA = The DevOps Research and Assessment team
• Deployment Frequency (Tempo)
• Using deployment lead time as a proxy for batch size. Reducing batch size reduces cycle time, flow variability, accelerates feedback, reduces risk, improves efficiency, increases motivation and reduces cost.
• How often do you deploy to production or to the app store?
• Options: OnDemand, hourly, daily, weekly, monthly, 6 monthly, fewer
• Lead time for Changes (Tempo)
• Shorter is better. Faster feedback, quicker course correction. Better in an outage.
• Two important periods, but only one is measured. Time to design and validate (hard to know when to start the clock). Time to build and deliver (easier to measure).
• Time from code committed to code deployed?
• Options: less than 1 hour, 1 day, 1 week, 1 month, 6 months, longer
• Mean time to Recovery (Stability)
• Failure is inevitable, so we ask how quickly can service be restored.
• How long does it take to restore service when there's an unplanned outage.
• Options: less than 1 hour, 1 day, 1 week, 1 month, 6 months, longer
• Change Failure Rate (Stability)
• What % of changes to production fail? Including infrastructure and configuration changes result in degraded service or require remediation?

• Use cluster analysis to identify high, medium and low performers.
• There is no tradeoff between speed and quality. High performers do better at all the measures. High performing customers are pulling away from the pack, their continuous improvement is increasing their lead.
• Software performance is a good predictor of company performance (profit, market share and productivity). Hitting goals, customer satisfaction etc.
• Companies should distinguish which technology is strategic and which isn't, and acquire non-strategic services as SaaS). Simon Wardley: Wardley Mapping Method.

Understand context and diminish risk: How to build your first Wardley Map with Miro

Wardley Maps are all about strategy. This is especially helpful if you are starting a business or a non-profit, inspecting the competition, analyzing opportunities or even trying to anticipate what the future might hold. Here's how you build a Wardley Map and collaborate with your team using a virtual whiteboard.



miro.com


• With a well defined measure of performance - you can start to develop a theory of how to improve teams

3) Measuring and Changing Culture

• Culture is important, but people think it's intangible and hard to measure.
• Three Levels of culture
• Basic assumptions: Formed between people, things you know, hard to put your finger on
• Values: You think you believe, more visible, can be discussed and debated. Used to make decisions.
• Artefacts: Rules, mission statements, objects, and procedures
• Organisational culture predicts the way that information flows through the organisation.
• Good information flow : provides answers, is timely, presented in a way it can be effectively used.
• Different types of culture
• Pathological: and power orientated: fear and threat, hoard information
• Bureaucratic: protect departments, protect turf, insist on rules, do things by 'their book'
• Bureaucracy isn't always bad. It's fair, could capture best practice of the organisation.
• Generative: focus on the mission, on accomplishing the goal, everything is subordinate to the mission
• Generative culture: trust, mission focused, level playing field (less hierarchy)
• 31% were pathological, 48% Bureaucratic, 21% Generative.

• Better information flow better performance.
1. Trust and cooperation between people across the organisation
2. Better organisational higher quality decision making
3. Likely to do a better job with people, problems are rapidly discovered and addressed
• Consequences:
• Technology is changing, you need to be resilient and responsive.
• Google found that team dynamics are more important than the individuals within a team.
• How failure is dealt with is a good measure. Pathological look to blame (but there's often not a single cause or person). Human error should be the start of the investigation.
• How do we change culture? Change how they people behave (what they do) before tackling how they think.

4) Technical Practices

• Continuous delivery is a set of capabilities that allow us to get changes into production safely quickly and reliably
• Key Principles of Continuous Delivery
1. Build Quality In (so less pressure on testing)
2. Detect issues quickly, so they’re cheap and easy to resolve
3. Work in small batches
4. Computers perform repetitive work tasks, people solve problems
5. Continuous improvement
6. Everyone is responsible (system level outcomes)
• To implement continuous delivery you need
• comprehensive configuration management - fully automated version control
• continuous integration
• continuous testing - all the way through building
• Impact of continuous delivery
• decrease deployment pain and employee burnout
• identify more strongly with the organisation that they work for
• higher levels of software delivery performance
• helps with sustainable development
• save time on rework (bugs and patches) {as a proxy of quality}
• Continuous delivery practices, what works and what doesn’t
• Configuration was more important
• Test automation: teams must be confident if they pass, they can deploy.
• Developers must right them
• Every commit should run fast tests
• Merge to trunk quickly (don’t have long branches - discourages tech debt work)

5) Architecture

• Low performers were most likely to be working on custom software built by other companies
• Testability and Deployability (must be designed for)
• Reduce dependencies across teams
• Architecture should map to teams
• Loosely coupled architecture is more scalable (per developer)
• Tool choice - let teams choose their own tools
• Build security into your work
• Focus on engineers and outcomes - not tools and technologies
• Design things so they have freedom

6) Integrating InfoSec into the delivery life-cycle

• DevOps is poorly named
• InfoSec teams are normally poorly staffed
• Build security into software development
• Shift left with security - review features as soon as possible
• Security should be involved in design
• Give developers the need to build security teams
• Rugged movement - refuse to be vulnerable - choose to be rugged - being rugged is everyone’s responsibility

7) Management Practices for Software

• Prince 2 dominated, then agile, then lean
• Lean Management Practices
• Removing work in progress
• Making metrics and dashboards visible (to engineers and leaders) - ease of access is key
• Use these tools to make decisions on a daily basis
• Changes with change review process, or just peer review, performed better than those that had it
• Approval by an external body slows things down and doesn’t improve reliability
• Segregation of duties + peer review + auditable pipeline = is great

8) Product Development

• Agile won the methodology war
• Companies still: spend too long on requirement, budgeting, large releases and customer feedback seems to be an afterthought
• Companies should: test products design and business model by frequent user testing
• Lean Startup: Experimental approach to product development. Lean and design thinking. Pivot early and often,
• Take an experimental approach
• Lean Product Development Capabilities
• Small releases. 1 week max. MVP
• Flow of work from business to customers. Make it visible to everyone.
• Actively and regularly seek customer feedback + incorporate it into products
• Development team have authority to change specifications as part of the process without approval
• Higher software performance, organisation performance and people performance (burn out).
• Software performance predicts lean product development practices. Virtuous cycle.
• Working in small batches. Making rapid development possible. Short lead times, and faster feedback loops. A/B testing.
• Team Experimentation: Seek input from customers throughout the process. Ability of teams to try out new ideas without approval is important.

9) Making Work Sustainable

• Deployment pain - avoid painful deployments
• Write software with deployability in mind
• Don’t handle configuration manually, as you get configuration drift
• To avoid burnout
• foster a respectful and supportive work environment
• strong sense of purpose
• invest in personal development
• asking what’s stopping people from achieving their objectives
• give people time space and resources to experiment and learn
• give them the authority to make decisions
• Burnout warning signs (fix the environment)
• too much work
• lack of control
• insufficient rewards
• breakdown of community
• absence of fairness
• value conflicts
• Lean management and continuous delivery reduce burnout
• What to do:
• Blame free environment
• Make deployments painless
• Effectiveness of leaders
• Investments in Dev ops
• Support experimentation and learning
• Give people some time to work on new and exciting projects
• align organisational values with individuals values

10) Employee Satisfaction, Identity and Engagement

• Hire, retain and delight
• Employee NPS - Higher NPS have higher retention
• How likely is it that you would recommend our company, product or service to a friend or colleague?
• 9 or 10 are promoters
• 7 or 8 passives
• 0 to 6 detractors
• Loyal employees are the most sticky and engaged
• invest in your people and let them do their best work
• Diversity matters - smarter, better team performance and business outcomes
• Inclusion must be present for diversity to take hold
• Grace Hopper Conference

11) Leaders and Managers

• Leadership is about inspiring and motivating those around you
• Transformation Leader Characteristics
• Vision
• Inspirational communication
• Intellectual stimulation
• Supportive leadership
• Personal recognition
• Transformational leadership - inspire, empower, develop, identify, engage, align
• Statistically significance and highly correlated with NPS
• Enabling practices - continuous experimentation and learning
• Conferences, tech debt time, hackathons, training etc
• Culture
• Climate of learning - space to explore ideas
• Safe to fail
• Space to share knowledge
• Let them choose their tools
• Make monitoring a priority

Part Two: The Research

12) The Science Behind this Book

• Primary Research - you collect the data
• Secondary Research - somebody else collected the data
• Qualitative - not numbers
• Quantitative - numbers
• Likert scale - strongly agree or disagree scale
• 6 Levels of analysis
1. Descriptive
2. Exploratory
3. Inferential predictive
4. Predictive
5. Causal
6. Mechanistic
• Population - entire group you’re interested in, sample - group you’re gathering info from
• Sampling techniques are therefore important

13) Introduction to Psychometrics

• Good survey questions
• Shouldn’t be leading
• Shouldn’t make people select an answer a question which doesn’t apply
• Should only ask one thing
• Clear language
• Start with a clear understanding of what you’re trying to measure
• Use latent constructs! Proxies for what you’re trying to measure
• Give us several views into the underlying theme
• You can also conduct tests - things that things you expect to be corollated are, and shouldn’t be aren’t

14) Why use a survey

• Reasons to use it
• Speed and ease (when compared to data collection across 1000s of firms)
• E2E results (can’t measure everything with data from systems, but can with a survey)
• You can trust survey data
• Somethings can only be measured through surveys (feelings and emotions)

15) The data for the project

NA

Part Three: Transformation

16) High-Performance Leadership and Management

• Organisational Transformation
• How to lead, manage and sustain
• How do we know what our customers value?
• As we learn, how to do we share it?

Lean Management Practices

• Priorities and objectives visualised - as it progress
• Colour coding makes problems visible
• matrix structure - value streams - squads - squads have product owners, are cross functional, follow the 2 pizza rule (biz dev ops)
• centres of expertise
• coaching of squads
• WIP is visualised
• Stand-ups but less meetings overall
• Problems remain visualised until they are solved
• Tribe lead visits squads to ask what they can do - leaders as coaches
• Develop the people
• Let people own quality - let them not release if they’re not comfortable
• Standard ways of working save time and energy

• How do we learn how to learn?
• Coaches question assumptions and challenge behaviours
• Do it in cycles, the it becomes routine
• Get people to share how they work

• Develop and maintain the right mindset
• Do things on your own
• Don’t contract out to a consulting firm to transform your organisation
• Demonstrate behaviours don’t delegate them