The project was of to a bad start: an inherited legacy codebase, a waterfall contract, and a projected loss. The promise of Kaizen or Continuous Improvement seemed very appealing. But when we tried to incorporate this into our process, it didn’t catch on. Biweekly retrospectives didn’t seem to expose any problems we could improve upon. The ceremonies we tried, like Deming’s Plan-Do-Check-Act cycles, added too much overhead. We were doing something wrong.
Continuous Improvement implies that you know exactly where to focus your efforts. Like scientists, we started to experiment, without deciding upfront what we expected the outcome to be. The rules? Make every experiment as small as possible. No meetings, no consensus, no cumbersome evaluation process. We let the results speak for themselves. This talk explores the successes and failures of a team that went from survival mode to learning mode over the course of a year.
mathiasverraes
sansantech
devops_vtj
n1ru4l
tomzoh
motsuhiro131
yud0uhu
ama_ch
mixi_engineers
odasho
nagix
th0x0472
prashantspol
productmarketing
geeforr
addyosmani
csswizardry
roundedbygravity
bkeepers
eileencodes
phodgson
brianwarren
bcantrill
zakiyama
maggiecrowley