Agile Austin "Attacking Things Incrementally"

Walter Bodwell spoke to 55 people at Agile Austin this month.

 

Yassar opened the meeting

 Walter was a great speaker.  He made the audience feel comfortable and people participated well.  We broke into small groups and discussed how to break down some current issues we had at work.

Here's my personal notes:

Simplicity the art of maximizing the amount of work not done is essential.
Small stories are best:  easier to estimate, enables earlier testing, less risk, faster feedback, easier to pivot, easier to tell when done.
Stories can be too small - overhead can be too big.
At least 5-9 stories per iteration.
Ideally .5 to 3 days  per story.

Barriers to small stories: get past all or nothing; some developers don't want to itemize large tasks, overhead can be too great.

 When splitting a story each "slice" should add incremental user value.
Reprioritize and resize after splitting

Who does the splitting?  Product owners and developers
Split stories vertically (Ui and Middle Tier and DB) so user can see value
Don't split horizontally e.g., DB, because user can't see value or be tested

Questions to ask yourself:
How will we test this slice?

Ideas for splitting:
Handle most important users first
CRUD - Start with just Create and Read; wait on Update and Delete
Do the happy path first
Make it work, make it work fast

Why Small Releases?:  Easier to defer to next release; earlier revenue opportunity; earlier feedback; pivot faster;

When doing a code rewrite, put both system out so users can still use old system.  Sometimes a feature is written in such a way that a customer can do something odd and create something very valuable to them which is not documented nor was it intended.