Scrum is based on rugby as mentioned in Takeuchi paper.
To win the game takes more than just playing your position
Finishing on time != winning
Individuals and pegs prioritise safety over success
Scrum is an agile strategy not the rules of the game
Even if ur in time ur prob wrong anyway
Ur guesses about the future are prob wrong
Even if really good = right about 1/3 of the time
50-80% software fails to meet outcomes
It's only after delivery that we really understand value
"Design thinking" focuses whole teams in solving customer & user problems
Edmunds.com, IDEO Tim Brown Change by Design
Empathy, define, ideate, prototype, test
Whole team
Not always sequential
Lightweight personas
Sketching independently
Sketch studio
Lean us
Share results
Internal "trade show"
Stop worrying about velocity & start focusing on winning the game
Adding lean Startup to fix agile
Working software over comprehensive doco
Kent Beck:
Validated learning over working software (or comprehensive doco)
Explicit release, measure
Goals in Rpv: revenue per visit
Adding lean startup to fix design thinking
Spend time learning rather than arguing
Process is a fame strategy and au to win
Invest in understanding problem
Invest in validating outcomes
Maximise ? Minimise ?
Do it anyway they don't know what you're doing anyway
Just do it award
Charles Nutter @headius
Drip
Indy
Graal Interpreter/optimiser
Truffle AST
Michael Nygard
Culture
Enablement
- make ops responsible for fast delivery
- make dev responsible for uptime
Share
- share power
-- tools from ops side that let devs self-deploy
- Share knowledge
-- Donella Meadows
--- "structure of info flows"
-- big visible displays - first way to introduce devops
Dev is prod
- Development infrastructure is mission critical
Statistical Sophistication
- Dan McKinley Homo Narrens
Cautions
- hype cycle
- the paradox of automation
System comprehension tools?
Patrick Debois
Monitoring Stream Mapping
- reverse vsm
1. Seeing the devops system
2. Focus on flow
- remove friction
- Tech debt vs social debt
- codifying-devops-area-practices
Example practices
- infra as code
-- same tech versioning/testing
-- executable doco
-- common language
- reproducible envs
- monitoring & metrics
-- enable devs to see prod usage/problems
-- make it self-servicing
-- devs can add metric to their code (statsd)
--- namespaces
-- make non-subjective decisions at start of project
- Devs wearing pagers
-- devs learn ops
-- ops learn dev
-- write better tests
- chaos monkey
- Zoome Atlassian
-- visualise prod errors frequency per group
-- enable extraction if context
- ChatOps
-- shared view
- Public post-mortems
-- chat makes it visible
- Game days
-- Find bottlenecks
- SadOps
- "You build it you run it"
Lyssa Adkins & Michael Spyd
Hiring Agile Coach
Silent release plan
ICAgile
Learning Objectives
Agile coach
Agile team facilitator
Be good at practitioner
Be good at teaching or mentoring
Be good at coaching or facilitating
Only one of tech/busn/transformation
Coaching lessons
Software ed
ICF
Email Lyssa
Sam Newman
Hexagonal Architecture - Alistair Cockburn
***Tip: Standardise gaps between services but be flexible about internals
Integration style evolution
- Data oriented -> procedure oriented -> doc oriented -> resource oriented
- further right = less coupled
Tip: Avoid RPC or shared serialisation
Have at most 3 ways of integrating - not 20
Books:
- "Web API Design" Apigee
-- cross some sections out
- "REST in Practice"
Tip: Avoid Distributed transactions/locking at all costs (CAP theorem)
Monitoring
- have to get *much* better at monitoring
- not badass if u use ssh multiplexer
- use synthetic transaction to test prod
- use correlation ids to help track down nasty bugs
Deployments
- abstract underlying deployment
- Tip: have a single way of deploying to any env
Testing
- integration test
-- lots of services = while to run, false negatives, poor isolation, large scope to blame
-- keep to a minimum, how to test other service without intg test?
- A -> B(v2)
- diff apps should know what resources they need
- Upstream (A) writes test that tests dependencies
- downstream (B) runs those tests
- "Consumer driven contracts"
- growing pile of pending stuff
-- big release = higher risk
*** - Tip: don't let releases build up - release as soon as possible, preferably one at a time
- if u can't fix that before building new service
Architectural safety
- cascading failure
- Tip: use timeouts, circuit breakers & bulkheads to avoid cascading failures
-- fail fast, don't pass up the chain
-- read Release It
Tip: Service templates make it easy to do the right thing for each deployment platform - implement conventions yourself
Delay the need to intro breaking change
- consumer driven contracts
- prefer ver # in URI
- coexist in same app as endpoints
Other Talks
- "Rapid release"
- "Macro to micro"
Aaron Bedra
Braintree
ModSecurity
"Carded", "carding rings" = criminals test stolen credit cards against your website to then sell on black market
- abuse of your infra
HTTP method Verb distribution is important
Getrepsheet.com
Adrian Cockcroft
bit.ly/netflix-workshop
Anti-fragility = enough stress
- Not to break or go flabby
Speed at scale = everything is broken
Karyon status page is machine and human readable e.g. Chaos monkey
Joel Pobar
32core, 144Gb, 3tb
Entire code base for all teams
Fabricator
- Image macros
ODS
Perf lab
Scuba
Cubism
