Tuesday, 29 August 2006
Showcase
Posted by Simon Baker
The showcase provides a visible and honest demonstration of the team's progress to the customer. It presents an opportunity for the team to obtain feedback and seek acceptance from the customer on the iteration's stories. It provides closure for the iteration. We use 1-week iterations and our showcases typically take 10 to 15 minutes. Here's the basic format:
Read more...
Tuesday, 22 August 2006
Respect the iteration timebox
Posted by Simon Baker
The iteration is a fixed timebox. And the showcase provides an opportunity to seek acceptance from the customer. It provides closure for the iteration, which can then be reflected upon in a retrospective. To maintain rhythm, it's important that the iteration review is held at the same time, on the last day of the iteration. Don't delay or postpone it. Respect the timebox.
Read more...
Friday, 18 August 2006
Build quality in
Posted by Simon Baker
It's worth being test-driven and working from the outside-in, starting with automated acceptance tests. And it's worth getting done in the iteration, which means performing any supplementary testing, e.g. adhoc testing on a per user-story basis in the iteration. This means that testing responsibilities and skills are an intrinsic part of the team and are colocated.
Read more...
Planning and plans
Posted by Simon Baker
Plans are of little importance, but planning is essential - Winston ChurchillPlans are nothing; planning is everything - Dwight D. Eisenhower
Monday, 14 August 2006
BAKER'S DOZEN: Statements from an Agile subculture
Posted by Simon Baker
At my current client, I've sown an Agile seed in a command-and-control environment. The organization's culture is predominantly process-heavy, document-driven and full of waste. Nevertheless, my seedling grows. Nurturing it every day, I was inspired to write these statements as I witness the emergence of an Agile subculture.
Read more...
Thursday, 10 August 2006
Modelling and models
Posted by Simon Baker
The value is in the modelling and not in the model. You model to explore and understand something better. The value is what you learn from the modelling experience. The model is a side-effect of the modelling and not the result. Don't waste energy trying to keep it in-sync with the source code as you move forward.
