These are some items from
Agile 2006 which interested me enough that I wrote them down.
- it's a wonder that spreadsheets don't have features built in to deal with uncertainty
- tooling to improve programmer efficiency makes software so much cheaper to write that much more software is worth writing: and so generates jobs for programmers, not the converse
- 3M apparently has a target for revenues generated by products less than three years old
- the value of a codebase is not dependent on the effort that went into building it
- nervousness is the enemy of innovation
- Agile development manifests the Kolb learning cycle
- if you wanted to cerify a team as Agile, maybe you'd only really need to certify the facilitators of the retrospectives
- maybe a retrospective (or similar explicit learning activity) is about deliberately moving from unconcious competence to concious incompetence
- ...and maybe also has something to do with Heidegger's distinction(pdf) of ready-to-hand from present-at-hand. Something that I've had cause to ponder before in its relation to software.
Ole Jepsen's session "Agile Meets Offshore"
- perhaps counter-intuitively, distributed teams tend to have shorter iterations than colocated ones
- You are likely in a difficult spot when people start saying things which can be given an "objective" spin but are really claiming the property on the left for themselves so as to imply the property on the right of you:
- natural vs artificial
- important vs childish
- life vs death
- have the "customer" provide estimates, as well as the developers: when the two are wildly different there's something to learn
- the size of a story as esitmated by the developers is independent of its business value
- the stories that happen to be in a given iteration are a random sample from the backlog
- using puzzle questions at interview discriminates against candidates who aren't white upper-middle class suburban American males.
- some white etc. folks find this idea rather upsetting
Ward's Ten Favourite Wiki Pages
- arguing for of refactoring is arguing for your own lack of ability
- if you don't know calculus you aren't equipped to "embrace change"