Moving Furniture: The Scrum Way

As a housewife, my wife
Wants the bed in one room swapped with the couch/futon/bed in another
So that  she can more comfortably sit and watch the Olympics on TV in the sunnier, warmer room.

With 3 programmers in the room, it was inevitable that we would choose an Agile approach to this requirement. The User Story above was our first step, and was duly agreed to by said wife as Accurately Describing What She Wanted and its Business Value.

Given the constraint that both rooms involved are too small to contain both pieces of furniture simultaneously, we realised that we would need a temporary variable as a swap space. I'm pretty sure that, barring some major advance in our understanding of Quantum Mechanics, pieces of furniture can't be swapped by being XOR'd through each other.

We broke the Story down into some Tasks:

1. Remove the bed from Room 1 into the Swap Space.
2. Remove the Futon from Room 2 into the Swap Space.
3. Move the Futon Base (a finger-eating piece of folding woodworkery) from Room 2 into Room 1 and position it in its final position.
4. Move the Futon from the Swap Space into Room 1 and position it on its Wooden Base.
5. Move the bed base from the Swap Space into Room 2 and position it in its final position.
6. Move the mattress from the Swap Space into Room 2 and place it on its base.

Seemed like a reasonable breakdown at the time. We did some estimations and figured we could fit it all into a single Sprint.

Here's how it played...

Task-1 went quite smoothly. Mattress and bed base moved to the Swap Space.

Task-2 also went well. Please bear in mind that the futon and mattress are large, floppy and heavy items, so not all that easy to move about.

Martin and I -- Pair Moving -- make an attempt at Task-3. Space is very constrained, so moving the Futon-base into Room 1 involves a brief detour into Room 3. Halfway there we suddenly realise that -- because the base is asymmetric -- we have to turn it around in the Swap Space before it can be Deployed into Production.

We complete Task-4, only to realise that we were entirely wrong about which way round the base has to go. We've moved it into the room the wrong way round. And the room is too small for us to turn it around short of Interesting Topological Manoeuvres.

So we back out again, via Room 3, back into the Swap Space where there is sufficient room to turn the base around.

Some discussion ensues. We realise that we should have had better Unit Tests in place for this Task. Finally we manage to complete the Task.

It's a tight fit, but the Futon/couch will serve our User perfectly as she wished.

Sadly there's an unforeseen bug. A small drawer unit now blocks the doorway, making for extremely poor UX. Not our problem, though. We've met our spec and implemented the Story. People will simply have to leap over the drawer-unit for the time being. Changes will have to be the subject of a subsequent Sprint.

Happily I can report that the rest of the Sprint went quite as anticipated. We were even able to implement a small Improvement Task by orienting the bed in Room 2 in a much more User Friendly fashion.

I do wish Furniture Topology was amenable to Version Control, though. It would have made our Task-4 issues a bit simpler to resolve. But then, perhaps we should have abandoned the Sprint at that point.

Still not quite sure how all the Scrum ceremony helped, though.

Work Wanted

This is a small call for help. I am looking for work, and need your help.

Contract or permanent. Preferably (but not exclusively or even at all) telecommute. I can code, design, architect software, consult in any of these (and dev process/team issues) and teach a variety of Java, OO Design and web development topics, and would be happy to do any/all of these. I additionally have some experience doing system administration work. I work in Linux/Unix environments and know next-to-nothing about Windows.

I've done web stuff, and loads of backend "heavy lifting" coding where reliability, scalability, etc. are important. I am not good at quick'n'dirty. Skeptical of the value of buzzwords and big-arse frameworks.

Check out my "business" website for more details about me and what I've done in the past.

R (as they say) "highly neg".

If you have anything suitable, or know of anything that fits, please drop me a line.

I will be in Cape Town and environs next week, so an ideal time to get together and chat about possibilities and opportunities.

Open Course Development

It strikes me that, whilst I am deep into the design of a number of programming-related courses, I am making a terrible mistake. The mistake of not talking about what I'm up to. The mistake of assuming the entire burden of course development.

Instead I ought to be employing Open Source development principles. At least some of them. Seems to me that (at least) the Thousand Eyeballs principle applies quite well, at least to the course structure, content and sequencing.

Right now I'm in the thick of codesigning three courses that I (with good reason!) believe are served very poorly by the corporate training world, and I think I can design courses that deliver much, much better value for money. The three I'm busy with right now are "Elements of Object Oriented Programming", "OO Analysis and Design" and "Patterns of Software Design".

"Elements" is intended as an introductory foundation course for programmers coming from a non-OO background who want/need to learn the OO concepts quite quickly. Nobody in their right minds would believe that a 3-day "Elements"-style course is going to turn any Natural programmer into an OO expert... we all know that the process of learning to Think Objects takes 9 months. But I do believe that it is possible to teach the foundation concepts really well.

"OO A&D" seeks to demystify the analysis and design process -- to the degree that it is possible to demystify an essentially creative process.

And, finally, the "Design Patterns" course aims to teach something useful about... well... design patterns. I've taught variations on this one numerous times over the years, but never really been satisfied with the value I was able to deliver, so I've completely rethought the approach from the ground up, and -- I think -- come up with something Just a Bit Different. A whole lot of the Design Patterns courses I've seen offered seem to add up to nothing more than a whole lot of droning through the GoF patterns catalogue. I think there's a whole bunch more to the topic than that, and I plan to use the course to explore that.

I've also outlined a whole bunch of other courses that I want to develop over the next year or so, but developing even these three is a daunting enough task for now.

I'm openly stealing some of the concepts -- the approach to teaching -- exemplified by the Head First books, and I'm really interested to see that O'Reilly are themselves developing a bunch of courses -- I gather they'll be web-based courses -- under the Head First brand. Good for them! It's about time we saw a better approach to teaching technical stuff.

So I'm aiming to make the courses colourful, interactive and fun. I'm trying to build in lots of of pictures, music, video, games, practical exercises, movement. (Trying to figure out how to include flavours and smells... ;-)

I've also been breaking away -- especially for the "Elements" course -- from linearity in the course sequencing. Essentially I'm developing using a Spiral Model. First introduce a concept, then go on to related concepts, etc., in time spiralling round to repeat the discussion of the topic in greater depth, and so on. I've long known that it is too easy to give too much detail all at once, so for my own course material, I'm explicitly shying away from that. I think it equates -- somewhat -- to the concept of Progressive Disclosure in user-interface design. As luck would have it, after several weeks working on this stuff, I tripped across this article just today, and went "Aha! Somebody else who Gets It!"

Right now I am stuck. Struggling to come up with good great practical ways of exploring the topic of "Encapsulation" in a way that doesn't stray too far from the way it's meant in OO programming, whilst remaining vaguely interesting.

As soon as I get the relevant bits of machinery up and running, I'll post the course outlines. (Will take a while: I am unexpectedly and suddenly off to London for a week for a spot of consulting work.)