Archive for February, 2005|Monthly archive page
it’s a boy!
Comments (1)Baby Rutherford was born at 9:45 this morning (Feb 28th) in Macclesfield hospital. He weighed 7lb 8oz and has a shock of bright red hair. He currently has no name. Mum and baby are both very well – daddy is a bit shell-shocked. First pictures on Donna’s website.
Update, 4 Mar 05
When we saw him, we knew instantly that he wasn’t an Andrew. So we’ve named him James Bramwell Rutherford. Or Spike.
bookcrossing
What a fantastic idea!
It seems that there are no books in the wild in Macclesfield just now though. I guess I need to put that right…
use spikes to manage technical risk
At the AgileNorth meeting on Monday of this week we recapped an old discussion about technical risk. Some months ago Phran Ryder had raised the question of how to prioritise stories during release planning. I have always held out for business value as the only factor to consider. Phran however insisted that his project was different, and that technical risk was more important. The topic came up again this week, and this time Phran was able to provide a very succinct explication of how we resolved the issue.
The dilemma is this: In order to deliver maximum value under all possible outcomes, we should prioritise our stories solely on the basis of their value as perceived by the Customer. But what if we can’t assess that value, or estimate the stories, in advance? What if we need to bring some stories forward to the front of the schedule, so that by doing them we gain further information to help us create the remainder of the plan?
Here’s a quick attempt at a conflict cloud:
(I’m not too pleased with this – please help if you can think of a better formulation of the dilemma.)
We resolved the dilemma by attacking the necessary condition at bottom-right in the diagram: we reminded ourselves that implementing a story isn’t the best way to obtain information about when to implement it! That’s the job of a spike (a throw-away prototype). We should do just enough work to obtain the information we need about the story. Just enough to put us in a position to correctly prioritise or estimate it and get on with planning the release. (At this point we must also throw away the spike code. Because the odds are very good that the world will be a different place when the spiked story comes to the top of the pile. If we kept the spike, it would likely require learning and re-work to fit into the new and growing system at that time. Best to just ditch it now and start afresh when the customer really needs it.)
the broad and narrow folksonomies
I had never heard the word ‘folksonomy’ before I read Personal InfoCloud’s Explaining and Showing Broad and Narrow Folksonomies. I think I understand…
keep the task board visible at all times
Your team holds a daily scrum or stand-up meeting. But for some reason you all decant to some other room for the meeting itself. Maybe you don’t want to disturb the other teams who share your bull-pen. Or maybe you’re used to meetings being in the Boardroom, so you just head off there out of habit. Or maybe someone once told you that a change of scene helps meetings to focus. Whatever the reason, don’t do it!
The daily stand-up should be about the tasks on the board. If the board isn’t in the room with you, the meeting will lose its structure. Sure, everyone will still take their turn in describing what they did yesterday and plan to do today. But without the task board there are no visuals for the listeners, no cues for the speaker and no controls for the coach or tracker. No-one can point to the tasks, so it becomes much harder to discuss tasks, disconnects, blockages etc. It is also now impossible to re-plan during the meeting. Finally, your task board should also be the place where you display your big visible charts. If you hold your daily stand-up somewhere far away, you can’t discuss them. No tactical analysis or retrospectives. No daily update to maintain momentum. Huge loss of communication. Huge loss of focus.
Read more »
“test” driven is a misleading name
As you may know by now, I’m very much against the name test-driven development. Mainly because what we’re doing in TDD isn’t really “testing” as seasoned testers know it. So following Brian Marick’s lead, these days I prefer the term example-driven design.
cargo cult software development
For reference, here’s a link to Steve McConnell’s great article describing “cargo cult” software development processes.
W = UH
Ole Eichhorn has a very simple formula for correctness: W=UH. That is, if something is ugly or hard, then by definition it is wrong. Simple.
UML is not a design tool
Yesterday I was speaking to a chap who had just completed a 5-day UML course. He’s a manager, and I asked him why he had taken the course. “Well now I can at least read the designs people do on my projects. And hopefully I can now also do some design myself.”
I’ve heard these misconceptions many times before – that UML is either a design tool or (worse) a design process. It isn’t. It’s a notation, based on an underlying set of concepts. Knowing UML does not make one capable of design, any more than one can become a chef simply by recognising food types and kitchen utensils.
UML has become an industry in itself. I can understand the commercial forces that caused it to happen, but I can’t help feeling that the resulting situation contains more negatives than positives. Sure, vendors can ply standards-conformant consultancy, CASE tools and training courses, but far too many people think that UML brings an essentially creative and intellectual skill (by which I mean software design) into the broader world. “Knowing” UML does not de-skill analysis or design. Knowing the UML notation does not make one a designer. But not knowing that does make one dangerous.
focusing on business value
I love it when the simple and elegant collides with the extraordinarily useful: Andy Pols’ Blog: Focusing On Business Value
