In chapter one, an assassin kills an entire family, but the toddler (always one to wander off) manages to walk out of the house without him noticing. The little boy walks to the graveyard just up the hill. The ghosts at the graveyard see him and hear the pleas of the ghost of his mother. They shelter him from the killer, and a couple of them adopt him. (Mr. and Mrs. Owens, married not just until death do them part but for a good 250 years now.)

The boy, now called Nobody Owens, grows up among the ghosts. He learns their ways and their skills. He never leaves the graveyard, because the assassin is still looking to kill him.

This is The Jungle Book set in a graveyard, with ghouls instead of monkeys and a werewolf instead of a python. There is adventure, danger, learning, fun, and some appropriately scary scenes (it’s a children’s book after all). There are delightfully weird characters. And in the end, of course, there is the inevitable return to life among other humans.

The book is imaginative, well-written, fun and poetic – everything a good Neil Gaiman book usually is. The plot is a bit shallower and the tone a bit more charming than in his adult fiction, but nevertheless really enjoyable. The one downside, according to some reviewers, is that it is perhaps a bit too closely inspired by The Jungle Book, but since I don’t have any fresh memories of that book (having last read it over twenty years ago) it never bothered me.

Adlibris, Amazon UK, Amazon US.

It’s official: we’re expecting another baby! ETA around September 28th.

I’m also releasing some previously-written but hitherto-embargoed posts in the Pregnancy category.

This is my summary of Diana Larsen’s “How Can You Manage New Organizations in an Old Way?”, which was the keynote speech for day 2 ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

The short answer is, You can’t.

Before discussing the differences between the old and the new, it’s useful to remember that the “old” way of work, command and control, has only existed for the past 80-100 years.

Now the old kind of work is being replaced by knowledge work, where the workers know more about their job than their manager does. The old kind of management no longer works.

Old management activities are: planning, organizing, budgeting, monitoring, directing, supervising, evaluating, controlling, commanding.

New management: managers focus on flow, people and value, and continuous improvement. Their job is to enable and facilitate.

New management activities include mentoring, mediating, protecting, advocating, acquiring and allocating resources, tracking and reporting metrics, supplying a good work climate, supporting learning, improving systems.

The people working are affected by the system they work in, and that is the reponsibility of management. Behaviour is a function of person and environment.

My opinion: This all seemed pretty self-evident to me.

This is my summary of Niclas Nilsson and Hans Brattberg’s “The Pair Programming Show”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

This session was a live play showing pair programming in action – done right, and done wrong.

My opinion: Fun and relatively well done, but pretty basic stuff. The only thing it gave me was a reminder of the different roles that the two people in a pair should have. One to focus on the small, immediate stuff; the other to focus on the bigger picture – Are we doing the right thing? Are we doing it right? Could we do something else?

This is my summary of Udi Dahan’s “Intentions and Interfaces”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

A core design pattern: intentional interfaces. Whenever you find yourself facing a design problem, tell yourself – “Make roles explicit”.

For example, a Customer class may be used to validate a customer before persisting it, for making customers preferred, and for adding orders to the customer. Making these roles explicit, the Customer class would implement IValidator<Customer>, IMakeCustomersPreferred, and IAddOrders. Now that these are in place, we may use them, for example, to implement different fetching strategies for #2 and #3 – lazy vs eager.

Another example: there might be a CustomerService class for those same three tasks. Separating out the three responsibilities, the class might implement IMessageHandler<ChangeAddressMsg>, IMessageHandler<AddOrderMsg> and IMessageHandler<MakePreferredMsg>. Now that this is explicit, we may split this into three different classes, which would (among other things) allow us to have several handlers for a single message, in a pipeline.

As a rule of thumb, define your interfaces starting from use cases. These tend to be a stable foundation to build on.

Often we think one interface – many implementations. With this pattern it’s the opposite: one implementation, many interfaces.

My opinion: This session is difficult to summarize without all the examples and step-by-step reasoning, so I’m afraid the blog post won’t do it justice. I found it useful, and the reminder to Make Rules Explicit will probably lead to better design with less sprawling classes in our code.

The moment the snow disappeared from parts of our garden, green shoots appeared. They must have been ready already under the snow, because this was all under snow just two days ago, and I think it would take more than 2 days for the shoots to come out. I like the way they come right through the rotten leaves, due to snow holding the leaves down I guess.

The white stuff around the shoots is not snow but some kind of weird mold that appears to have thrived under the snow.

This is my summary of Chris Hedgate’s “Effective Retrospectives”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Note: In Agile development, a retrospective is a meeting at the end of an iteration (which a period of work, usually 2 to 4 weeks) where the team reviews the iteration together, and discusses possible improvements to their process.

A bad retrospective is: ad hoc, not prepared, with no structure.

The goals of a retrospective are two:

  • participation
  • decide on actions, what should we change (this is what new scrum masters often focus on)

Keys:

  • Facilitation = planning, leading, setting a goal. Gives us flow.
  • Framing = setting up and ending, making it focused
  • Structure = ensures balance, gets everyone’s input

Facilitation

  • Use an external facilitator. The person leading the meeting should not have an interest in its outcome. It is difficult to lead and participate at the same time. If not possible: be very clear about when you’re leading and when you’re participating.
  • Work with the energy and the dynamics of the group. Take breaks; split into smaller groups when appropriate.
  • Prepare. Think about what activities to use; when and where to have the meeting; is food needed, etc.

Framing

  • Modify the retrospective according to its purpose
  • Define the goal and agenda
  • Not every retrospective needs to be about “how can we get better”
  • Try retrospectives with specific themes: QA, communication, etc – gets you away from boredom and routine
  • Start with a check-in: everyone says/draws something about the iteration
  • Make it safe to participate

Structure
A retrospective should have three phases:

  1. What happened? Why are we here? – In this phase we share context
  2. Why did that happen? – In this phase we diverge, by brainstorming
  3. what should we do? – In this phase we converge again, and decide on actions

Sharing context can include:

  • Looking at raw data: burndown chart, story list, bug count chart
  • Creating a timeline: write post-its with things that happened and stick them on the timeline (all at the same time or with individual preparation)
  • An emotional timeline (a line chart scaled simply from – via 0 to +, and everyone draws their own line between these extremes)

During brainstorming, people write ideas and thoughts on post-its.

During the convergence phase, you can cluster the post-its, vote on them, discuss them in smaller groups, etc. At the end, the team commits to actions that are

  • possible
  • valuable/important
  • someone who wants to do it

Finally, summarize: what have we learned, what are we taking with us.

My opinion: This was exactly what I needed. Chris’s comment about how inexperienced scrum masters always focus on “what should we change” really hit home. And our retrospectives have become relatively boring. This session gave me lots of useful, practical tips. I believe our next retrospective will be much better than the last one.

This is my summary of Bill Wake’s “To Make a Long Story Short – Splitting User Stories”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

Why split user stories? A story may be too big to manage. Or different parts of it may have different value. Or some parts may be better understood than others. We’re looking for bargains: best value for least cost.

There are 4 categories of splits:

  • high-level splits that get rid of lots of work
  • “ilities” – non-functional splits
  • UX splits – simplify the user experience
  • behavioral splits – simplify behaviour

Technical splits are not recommended. Stories still need to make sense and be valuable to users.

High level splits include: research; partly manual process (instead of full automation); buying instead of building; deferring features.

“ilities” splits include: static data instead of dynamic (a “refresh” button instead of constant automatic refreshes); simplified persistence; lower fidelity; lower reliability; lower performance.

User experience simplifications include: batch processing instead of immediate response (generate reports off-line overnight); single user (instead of multi-user); API only (UI can wait); simplified UI style; a generic UI (textboxes in a grid instead of nicely aligned dropdown boxes etc).

Behavioural splits include: happy path first (ignore alternative flows and exception cases); fewer choices (0 or 1 instead of many, e.g. fonts in a text editor); base case first (wait with a more general solution); collect less data.

My opinion: Pretty basic stuff rather dully delivered. I could have just taken the one-page handout and not missed much.

This is my summary of Brian Marick’s “Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism”, a session I attended at ScanDevConf 2010. Please understand that, except for the notes at the top and bottom, this post reflects the opinions of the speaker, not me.

There is a core in agile that is going missing now that Agile is going mainstream and crossing the chasm.

A problem with Agile is its name. Of course everybody wants to be agile. Look up the opposites in a dictionary: sluggish, torpid, immobile. Who wants to be sluggish and torpid?

So I came up with a description of Agile that is weird enough that nobody is going to immediately, before they’ve had time to really understand it, react with “oh yes, that’s me”: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

  1. Anarcho-syndicalism:

    • Worker self-management – no managers
    • Direct action. To take an example from the original anarcho-syndicalism, say you have a strike, and those opposing the strike are attacking you with clubs and guns. The standard approach would be to vote to elect a congressman who passes laws that prohibit violence against strikers. The AS approach is to get your own clubs and guns and protect your strikers. Don’t try to get into management to fix your problems, fix them now.
    • Worker solidarity: the team fails together and succeeds together, we’re all in this together
  2. Team-scale: we’re not revolutionizing society, just helping your team
  3. Artisanal: people on the team care deeply about the product and its users, sometimes more than the business. Counteracts the risk of becoming so infatuated with our process that we lose sight of our aim.
  4. Retro-futurism: 1930s futurism pictured all sorts of nice things for the future, i.e. for now. Orbital cities, clean cheap urban transport, underwater cities, personal jetpacks. We didn’t really get much of any of that. The same happened with Agile. In the early days agile projects were few and far between, but everybody hoped that the idea would spread and make all developers happy. Instead we now have lots of teams doing Agile in name only. People on “agile” projects are saying “at least my job doesn’t suck as much as it used to” instead of “this is the best project I’ve ever worked on,” which is how it should be. Retro-futurism reminds people of the possibilities. Don’t accept things as unchangeable, change your circumstances to get where you want, keep that gosh-wow spirit.

To summarize the spirit of Agile:

  • scrappy – we are trying to do something here, get out of my way
  • care – for the product, the users, the process
  • naive optimism

My opinion: Inspiring! Brian was an enthusiastic, passionate speaker who delivered a thought-provoking speech. New ways to think about old things. Conference sessions tend to fall into two categories: those where I learn new facts, and those that simply energize me and make me want to get back to work and improve everything. This is a prime example of the latter kind.

If you find this interesting, there is a bit more information at ARxTA.net, including a video of Brian delivering a similar talk some years ago at some other conference.

During this pregnancy (thus far at least) I haven’t experienced anything like the absurd all-consuming hunger I felt last time around. I eat a little bit more, and need an extra snack now and again to keep my blood sugar level.

But just like last time, I want cool, light, juicy food above all. Yoghurt and fruit are especially good. Some days I notice a lovely cake or cookie somewhere, and really wish that I wanted to eat it – but when given a choice I’d much rather have some grapes. The best meal is unsweetened yoghurt mixed with some berries from the freezer, and Havre Fras (puffy oat cereal). I’d been wondering what we would use all those berries for (cause we have lots). Now I know: to build a baby!

My body never quite regained its original shape after my previous pregnancy (even though I quickly tumbled back to my original weight). And now my waist is getting rounder again. Most of my “smart casual” skirts are already unusable; the dresses still fit, and some trousers too. Time to unpack the pregnancy clothes again. How lucky that we’ve managed to time this pregnancy to match the seasonality of the previous one almost exactly!