Why We Need Architects (and Architecture) on Agile Projects
summary
Argues that architecture must be explicit on larger agile projects to avoid crippling architecture debt, using concrete practices: timeboxed design innovation spikes (hours–days for small spikes, up to six weeks for big experiments), refactoring guided by tests, CRC-style lightweight models, and an architecture kanban/backlog to make work visible. Notes team-size signals (small teams ~6–8 let architecture largely emerge; projects with ~250 developers need coordination), shows landing zones with min/target ranges used at Freddie Mac, and reports these practices reduce integration risk.
AI-written summary · about
chapters (8)
- 0:00Why architecture matters
- 3:26Balancing size and risk
- 15:28Architecture for large teams
- 23:23Upfront planning
- 30:56Managing risks with landing zones
- 41:52Tools for architectural risks
- 44:21What agile architects do
- 49:42Signs of good architecture
related talks
01h 02mWhy We Need Architects (and Architecture) on Agile Projects
38mAgile Architecture
01h 09mAgile Software Architecture
13mAgile Architecture: Enabling Innovation in a Rapidly Changing World
01h 03mAgile Software Architecture
53mAgile and Architecture: a meeting of the undead
49mAgile and Architecture: a meeting of the undead
08msoftware architecture and agile development