Keynote: Chestertons Gate: Always Ask Why

Key learnings

Want continuous delivery? Start by not revealing the due date. Instead, insist that the product must be ready at any point with a two week backend.
Want agile development? Reduce the sprint size to the natural developer cycle, the time from one successful build to the next.
Want software that meets your needs? Bring agile development processes into the surrounding process (requirements gathering, funding approval, system test and delivery)
Use requirements tests, not requirements docs because each doc looses fidelity as context is lost (why was this requirement generated, what is the context of this request?)

Why do we use waterfall?
Why do we use waterfall in the processes surrounding the development phase, even when the development phase is "agile"
Why do we do agile development, in waterfall-like sprints?
Why do we do architecture (which is attempting to apply structure to complex, hard to change later portions of the software.
Why do we "document" the requirements. Instead, they need to be linked to the actual implementation by architectural tests that will fail if the implementation begins to violate the requirements.
Why do we have "applications" when the client simply needs an API built from composition
We talk about continuous integration, but what we need to move toward is continuous delivery.
Don't tell developers when the end date is. Instead, tell them it must be ready at anytime, with a two week backend. This forces the development to focus on continuous delivery, product that is incrementally developed and potentially always ready to ship.

Techniques for getting there