Belgium Agile Open - Spring 2009

I've just participated in the Belgium Agile Open - Spring edition 2009.

It was a great event and I learned quite a lot.

1. How to handle changes to existing user stories:

- in scrum, 3 of the most important events fall together: review, retrospective and planning... and thats not good at all. I have to learn more about Kanban / Lean :-)

- the user story format "as a" ... " i want to"... "because" .... is really adding value.

- the only valuable feedback is when you have a piece of software in production. That's all that matters!

2. Agile Testing:
- keep into account the cost vs the value when automating tests, applying the Moscow-principle

3. Agile Documentation:

- get feedback from your online help (monitoring what users type in the help search box)
- use a FAQ for users
- update your informatice workspace during development.
- apply 'Telling a Story" from the book "Working Effectively with legacy code"

4: Agile Consortium:

- it's a Benelux consortium, which probably will have a lot of influence soon.
- they will provide certifications, we'll need have to have in our curriculums
- they can make it easier for us to "sell" Agile
- it's a marketing thing :-)

5. Manufacturability of software:

- what do they mean by manufacturability?
- a good software design is simple
- a good archtecture is testable, loosely coupled
- the harder it is to 'disassemble' your software is, the higher the cost to maintain and change it 

6. Dimensional Planning:

- there is a big difference between incremental and iterative development. Xavier has made a great blogpost on the subject.

- dimensional planning adds another dimension to planning, which is Depth.
  • dirt road: This level is the manual work around
  • cobblestone road: This level is the bare minimal implementation
  • asphalted road: This level is the sober implementation
  • highway: This level is the full implementation
- Scrum does not encourage the Depth dimension. You can do it with Scrum, but it's not encouraged.

- Inxin has some presentations on Dimensional Planning.

7. Fit/Fitnesse:

- a great advantage of using a tool like Fit /Fitnesse is that it encourages communication between customers, testers and developers.
- Gojlo Adzik published Bridging the Communication Gap and it got a lot higher on my wishlist. :-)

It was the first event I attended that correctly applied the Open Space Technology. Congratuliations to our hosts: Peter, Koen and Patrick, and thanks to everyone who contributed.

Listening to PodCasts


Once in a while I like to listen to a podcast about software engineering. It's a great way of learning from 'the great' when they discuss particular subjects.

The open source tool I use for subscribing to the Podcasts is Juice.



My favorites are:

Book Review: Working With Legacy Code


Michael Feathers defines legacy code as “Code without tests”.  Based on that definition, do you work on legacy code? Probably almost every programmer gets confronted with parts of code not covered by Unit Tests. Do you want better techniques to work with code that doesn’t have tests?

If you take up the challenge of reading and applying this book, you’ll learn several specific techniques that you can employ to take this code, make the absolute minimum number of modifications to get the code testable. Then you’ll feel safer applying your usual refactoring techniques or doing the changes you need to make.

Example titles in this book are “This class is Too Big and I don't want it to get any bigger”, or “I need to change a monster method and I can't write tests for it”. Who hasn't encountered these problems? In these and other chapters, Michael practices several dependency breaking techniques.

Other chapters show how to write tests that help you understand the current behavior. Other chapters include handy techniques for understanding code, such as Telling a Story, Effect Sketching, Scratch Refactoring and Telling a Story.

I use this book when I inherit a set of code that just doesn’t have any tests, and I have to make changes to it. If you find yourself staring at blocks uncomprehensible code, you should do the same.