- Published on
Accelerate
- Authors
- Name
- Josh Haines
- @joshhaines
Notes
NOTE
This was the first book I ever added to my book shelf. I was expecting to write a table for each book detailing important points and actions I'd take for our internal Software Factory team. I've removed a bit of that, but decided to leave this formatting as-is to remind myself of the initial plans and how much they have changed.
| # | Notes | |
|---|---|---|
| 1 | Developers need to be able to run tests and run apps on their workstations | |
| 2 | Successful teams had adequate test data to run their tests. Consider making test data as proxy for all real data. | |
| 3 | Maturity models don't make sense, need capability models for evaluating | |
| 4 | Teams should be able to choose their own tools based on users of the tools | |
| 5 | Keeping system config and app config in version control is more important than application code | |
| 6 | Devs need to create their own tests, not made by another team. Also if tests pass then code should be releasable | |
| 7 | If devs are full time, trunk based is best with daily merges back to master and short lived branches. Open source or part time projects can have longer branches a la github flow | |
| 8 | Consider team apis and bounded context as a way to more loosely couple teams. High performance happens when a team can change the way it works without permission of other teams. | |
| 9 | Letting people use their own tools contributes to software and organization | |
| 10 | IA and IT Security should provide libraries and tools to devs and engineers and make their use optional but encouraged. | |
| 11 | Architects should focus on engineers and outcomes, not tools or technologies. Doesn't matter if developers hate using them, focus on people and what they want. | |
| 12 | Infosec and IA need stop be involved throughout, can't be a bottleneck at end as changes are hard and expensive. Plus it slows down our goal of fast deployments | |
| 13 | Rugged Manifesto is alternative to DevSecOps | |
| 14 | Having a manager or change board review deployments doesn't work, doesn't lead to better performance. | |
| 15 | Traditional IT Approval processes are risk management theater | |
| 16 | Consider formalizing 20% time, Friday afternoons, or time to work on any other project for the company. | |
| 17 | Yak days (for technical debt) and half days (for other ). | |
| 18 | Allocate training budget and let employees use it how they find . |
