malvasia bianca

And now day 2 is over. Better than day 1: I enjoyed all four talks that I went to, and hopefully got something out of them.

One of the problems that I have is figuring out which talks to go to. I have enough agile experience that I’ve been avoiding the beginners’ tutorials. The main basic practice where I feel lacking is in customer (or Customer) interaction; I’m not sure that my problems in that regard would be best solved by going to a tutorial on the subject. On the other hand, I’m hardly a grizzled veteran – maybe I don’t know my own ignorance, so maybe there’s really important stuff that I would learn from tutorials (on that or other subjects) if ony I went to them.

Still, that’s one way to narrow down the options, which is important given the large number of sessions to choose from. (And then there’s the open space stuff which is getting organized ad hoc, and which past attendees say can be the most rewarding part of the conference.) But it would be nice if I had a more positive approach toward selection: is there something that I really feel that I’m missing, and need to learn about? I don’t have a great answer there, either.

So, in retrospect, I should have approached the planning in a bit more TDD-ish fashion, with some idea of acceptance tests before starting the conference. Oops. Most of the sessions look interesting; if several all look approximately equally most interesting, my first coin flip is how easily I could imagine using it at Sun – they’re sending me here, so they should benefit. But if something is much more interesting but less directly applicable, I’ll go to it instead – I know from experience that I’m much more productive when working on things I’m interested on, and that it’s hard for me to predict what actually will end up being useful in my future life.

If any of my coworkers are reading this while the conference is going on, feel free to go to the conference web site and suggest sessions that I should attend. Or any of my other loyal readers, for that matter.

Anyways, enough blathering. In general, the theme for sessions that I attended today was bringing about change. I don’t think I have too much concrete to talk about what I learned, but it was interesting hearing reports on the subject from several fronts. And I got some good book recommendations out of it. Not clear directly how this will apply at work – it’s not even clear to me in what circumstances at work it’s appropriate for me to be an advocate for change – but I hope it’s not completely irrelevant.

The talk by Christopher Avery on leadership was worth mentioning, if for no other reason than that it was an interesting counterpoint to an earlier blog post. Like Holt, Avery makes the point that responsibility is important and doesn’t mean wallowing in guilt and blame. And like many consultants, he has a list of stages; his is “Denial, Lay Blame, Justify, Shame, Obligation, Responsibility”. In any given situation you typically proceed through these steps, frequently getting stuck at one; you may also go to a special stage “Quit” at any step of the process.

The interesting thing here is the stages “Shame” and “Obligation”. Saying “yes, I screwed up, that’s my fault” would frequently be called taking responsibility; and, indeed, it’s much more responsible than the earlier stages of blaming other people or explaning away the results. But it’s ultimately lacking: it’s all well and good to accept blame for something, but if you just leave it at that, you haven’t done anything to improve the situation, so it’s still a way of avoiding responsibility. Similarly, doing something because you feel obligated to even though you really don’t want to do it is better than flaking out; but it still isn’t a way to constructively move forward, because there’s probably a problem somewhere that should be dealt with but isn’t.

Not entirely clear what I’ll do tomorrow. There’s a tutorial on systems thinking; I could learn something from that. I think I’ll go to an open space discussion lead by the promiscuous pairing guy on lessons we could learn from waterfall. That will cover the morning; the afternoon is less clear to me. Also, somebody is giving a tutorial on C++ unit testing in the morning; I don’t want to attend, but I should probably track down the speaker after the talk to pick his brain.