Code And Cocktails

Agile Project - House Renovation - Analogy/Anecdote.

| Comments

I'm not sure why it took me so long to notice this analogy/similarity[1]
but when W. and I had part of our house renovated it was done in what,
if it were software, I would definitely call and "Agile" methodology.

I don't remember if I was aware of "Agile" at the time (having come to
this bandwagon rather late) and I was the "Customer" for this project -
but now looking back I see the following connections:

1. Weekly iterations - While not all 'stories' were done for us to see
each week - we did meet with the project coordinators each week and they
reviewed what got done, and what was going to get done and made sure we
were OK with how it went. If we changed our minds, or realized that we
wanted something different - the plans could change[2]. This is also
where issues were brought up - some tasks ran into problems (it is an
old house, there are strange and bizarre bits of construction in it
hidden behind the walls) which also led to changes in the plan. We were
always working on "stories" which we felt we must get done, sometimes
choosing to change which "stories" were to get done.[3]

2. Continuous Integration/Delivery - Since the work was taking place in
our own house (which we were still living in) we could take the latest
'drop' and check it out. How did the new room look (even if only framed
with no drywall)? Maybe the door should swing the other way (now that
we see how the walls actually _are_)?

3. Incremental development - obviously all construction is in a sense
incremental - first you frame the walls, then the drywall goes up, then
that is painted, doorknobs put on etc. As time goes on - big changes
become harder - but with the continuous feedback those changes can be
made earlier - we could see how things were shaping up as they went.

4. Retrospective - along with the weekly meetings I remember being
asked about if the meetings were working out OK - if we had any issues
with the way the construction was happening while we still lived there
etc. I.e could the process be improved.

5. Acceptance Tests - a "story" was not done until we were satisfied.

(Luckily, however, no Test Driven Development - wouldn't want them to
"fail" a load bearing wall before they built it!)

In all I'd class this house renovation project as sort of "Agile"
project and I think it worked out well. Knowing what I know now I think
I could have worked as "Customer" even better.

Footnotes: [1] I just got "Agile Principles, Patterns, and Practices in C#"
[Martin & Martin 2007], perhaps reading some of the front matter brought
this anecdote to light.

[2] For a price of course!

[3] But if a "story" started we couldn't really stop it (you can't
un-demo a room!) of course.

Personal Agile/Craftstmanship Manifesto

| Comments

I write tests first, then code, to ensure the code does what I intend.

I refactor mercilessly to ensure the code is as clean, expressive and
well designed as possible. The unit tests help me do this by keeping my
code doing what I intend for it to do.

I automate my acceptance tests for the same reason I do unit tests - so
that when integrated my collection of code works as intended.

I release my code frequently so that I get feedback from those giving me
my requirements; to ensure it does what they need it to do, and so the
priorities/requirements can change quickly. My automated tests allow me
to do this as smoothly as possible.

I search out tools/techniques which help me find problems in my code,
and which help me write the correct code faster & better.

I strive to always learn, to always improve.