The end of 2004 - part 2

Natural milestones like the end of a year tend to bring out the reflective side in me. (And in others too). What exactly was my experience of 2004 as I look back at it? What did I lose, or gain, or forget, or learn in the last 12 months? Searching questions without easy answers to think on as the New Year approaches...

The end of 2004 - part 1

For more than a hundred thousand people who happened to be near the Indian Ocean at the wrong time, the end of 2004 meant the end of their lives. Please help them by donating what money you can - if not for the reasons of compassion and humanity that I feel, then for the sake of your own self-interest (to rebuild the infrastructure that supported the sweat shops which may have made many of the goods you bought in 2004). Thank you.

More on Dave Snowden and Cynefin

Marc Ever's blog has a link to Ton Zijlstra's post Every Signal Starts Out As Noise with more information on Dave Snowden and Cynefin. It inludes this picture taken from a presentation by Dave Snowden (ppt) (copyright IBM UK Ltd. 2003) which describes a model of the four realms of knowledge and the way in which we analyse and interpret Cause & Effect in each of them.

The challenge of Thread Level Parallelism?

Tim Bray recently wrote about the impact of TLP on software developers: This doesn’t mean it’s easy. My Zeppelin project has client-side and server-side code, and both sides are highly parallel; it has been a complete fucking nightmare to debug, and I claim to be good at debugging. If we’re going to empower application programmers to get the most out of the high-TLP chips, we need big advances in development and debugging technology. I think the key thing isn’t so much better debugging technology as better testing technology. Given JUnit or equivalent, I’m pretty confident that I can pull together a good set of unit tests for just about any conventional single-threaded application. But when it gets parallel, there’s a problem in that I don’t have a general mental framework for how to build a test suite. Once we figure out some of design patterns, there are grounds for hope that we can do some tooling around it for testing and debugging.
I have heard this sort of comment before and know that there are folk out there in the TDD community who have experience with and solutions for designing (and testing) parallelism. If you fall into this category then now seems like a good time to start sharing what you've learnt...

Introspectives

Esther Derby's recent posts on annual reviews (summary: don't do them, at least in the way that most people do them) made me think of a tool I used recently that I called "introspectives". People on the project wanted feedback in shorter timescales than the drawn-out end date allowed and there was little time available to conduct meaningful performance reviews. (It didn't help that the project management were also nervous of allowing widespread participation in retrospectives, perhaps because they feared that they might give voice to dissatisfaction with the way that the project was evolving).
I wrote up a guided questionnaire that I hoped would allow individuals to think through their own experiences on the project and learn from them. I wanted the sequence of questions to lead from the objective to the subjective, and from the past to the future, somewhat like this:

• Perspective: project joining date, current date, co-workers since joining
• Skills: acquired, used, unused
• Highlights / achievements: project, team, personal
• Regrets / mistakes / missed opportunities: project, team, personal
• Lessons: Were the expectations that you started with on the project justified? What one thing would you most want to do differently if you started on the same project over again? How will you act differently from now on? What learning will you take with you from this project to the next one?

Interestingly, although I offered to spend time with people talking through their "completed" introspectives almost no-one wanted to do so, saying that the value of the exercise had been the thinking that they put into it themselves. So, overall I'd say that it successfully stimulated some worthwhile self-reflection. Let me know if you have used a similar technique, or if you try this and find it useful on your project.
Postscript: This quote from Naomi Karten (one of my current favourite quotes) sums up what I was hoping to achieve through introspectives: Our challenge is to remember to stop and ask, 'How might I have contributed to the situation? What might I have done to prevent it? What can I do to avoid a recurrence?'

More on fatherhood

I love my kids. I have done ever since I first held a warm newborn body to my chest; I do so even though they argue with me and with each other; and I will do even after they have grown up and left to make lives - and perhaps babies - of their own.
As a parent I know that I will always be there in their minds, sometimes scolding and sometimes encouraging. But as my children they will always be here with me in my heart.
Becoming a dad is a funny thing - noone tells you what to expect because noone can. Each child is its own bundle of hopes and fears, and tears and joy.
I love my kids.

(Written at AYE in the 10 minute exercise at the Writing Workshop).

What advice would you have liked to receive when you were a new or expectant father?

Becoming a dad...

...is the biggest change that I've ever experienced
...is wonderful and life-enhancing - even though the responsibility takes away some of the freedoms I took for granted
...was harder for my partner initially than it was for me - exhausting, painful, messy, drawn-out, and emotionally draining
...helped me re-evaluate my priorities and question the way I live my life
...filled me with awe for the beauty and fragility of new life
...made me realise that not every employer understands how important and rewarding it is to spend time together with your family (and fortunately I haven't worked anywhere as appalling as EA Spouse has had to work since I became a dad)
...is a challenge that never ends - but also one that never ceases to surprise and delight me

[grid::fatherhood]

Gridblogging software dads

At AYE Dave Hoover and I talked a bit about being a Dad in the software industry. It's a subject dear to my hear but not one I have read (or written) a lot about. Dave proposed that we both write a blog entry on What advice would you have liked to receive when you were a new or expectant father?, and invited other software Dads like Alan Francis, Richard Watt, and Laurent Bossavit to join in, "gridblogging" style.
So consider this an open invitation to join the mass blog posting on December 17th: it's time to get drafting!
Postscript: Alan suggests using [grid::fatherhood] to identify your post.

Standing up at TVASIG

At the TVASIG meeting last night we ran through Bill Wake's stand-up simulation "Second Agenda". It threw up a couple of ideas I'd been taking for granted:
- Hold the stand-up around your story wall / backlog chart: having the big picture at the stand-up helps to maintain focus and frame any discussion.
- Don't make your stand-up the very first activity of the day: allowing team members a little bit of time to socialise before the stand-up allows those morning-after-the-night-before 'aha moments' to be discussed outside the full group (most of whom probably aren't interested in that level of nitty gritty detail).

NB: We used Mike Cohn's description of the Daily Scrum to provide some background and orientation.

I'm a Thoughtworks Alumnus

I left my position at Thoughtworks a couple of weeks ago to start working as an independent consultant. (So if you're interested in working with me then please get in touch!) Apparently this makes me a "Thoughtworks Alumnus", which I find rather odd. If I have "graduated" from Thoughtworks then what does that make my ex-colleagues that are still working there? Who are the students and who are the teachers..?

Interviewed by Software Development magazine

This month's People and Projects newsletter includes an interview with me. I was delighted to be asked to talk about coaching, management and team behaviour, and I hope that some of what I said resonates with other people's experiences.
One of the questions that I was asked that didn't appear in the final version of the interview was about being a father, and since I don't feel that I write enough about that aspect of myself I've posted it here.
How has becoming a father affected the way you think about project management? And how do your project management skills affect the way you think about parenting?
I don't think that the two are closely related. The focus of project management is achieving difficult goals through team work, whereas parenting is much more about giving children the confidence and skills that they need to comprehend and survive in the world. I would actually say that parenting and coaching have much more in common: both are about trying to develop individuals by passing on concepts and behaviours. (That said, my ability to juggle several different problems at work certainly increased when my children were small and I was juggling more often at home!) Some project managers are willing and able to take on a coaching role for themselves, among all the other roles their organisation expects of them, but in my experience that sort of manager is scarce.

Refactoring Dysfunctional Teams

My workshop at XPDay was called "Refactoring dysfunctional teams"*. The premise was to explore some of the organisational beliefs and norms underlying Conway's Law (that dysfunctional teams produce dysfunctional products). I have heard people discuss dysfunctional behaviour without considering the causes of that behaviour, and I wanted to think about what those causes might be in practice.
My premise was that many of the causes of dysfunctional behaviour are organisational and not specific to individuals (not a novel concept I know, e.g. Systems Thinking covers this ground more deeply). For instance the belief that people on late projects will be punished fosters the attitude that "we don't have time to do it properly", and dysfunctional behaviour follows from there. Unfortunately the session was time constrained, and although a lot of causes and symptoms of dysfunctional behaviour were identified there was not enough time for brainstorming solutions.
Personally I think that considering my own behaviour is one of the most appropriate places to start addressing team dysfunction. Is my action or inaction tacitly supporting organisational norms that I disagree with? Am I behaving in a congruent fashion or not? What can I say or do (calmly!) that would make the situation feel more comfortable? If I consider questions like these, and through my example persuade others to do so too, then gradually we can affect the team's dysfunctional behaviour.
*As several people pointed out this is an inappropriate use of the word refactoring. Refactoring is concerned with behaviour preserving transformations and in the case of a dysfunctional team you probably want to change the behaviour, not preserve it. With hindsight "Understanding dysfunctional teams" would have been a better title.

XP Day 2004

I'm a bit behind with my blogging at the moment - XP Day was a week ago now. But it was a great event, organised by practioners for practioners, and there were lots of people there to talk to and swap experiences with: Rachel Davies, Andy Pols, Willem van den Ende, Joseph Pelrine, Duncan Pierce, Clarke Ching (who gave an excellent talk on Goldratt's Theory of Constraints), Steve Freeman, Nat Pryce, Joe Walnes, Olivier Lafontan,Dafydd Rees, David Leigh-Fellows, Ben Mitchell, ... and the list goes on.
The highlight for me (and I suspect most people) was the mind-expanding keynote given by Dave Snowden on the first day. In a wide-ranging talk about "sense-making, networks and narrative" he discussed causality, order, complexity, heuristics, attractors, barriers, probes, and grameen banking: all in the context of people and their interactions.
Some of the nuggets he threw out were that:

• people know more than they can say, and say more than they can write down - so if you want to capture knowledge then capture spoken words, not written ones
• people don't believe that success is predictable but do believe that failure is repeatable - so if you want to learn from other people listen to their war stories and mistakes, not their successes ("trying to avoid worst practice rather then repeating best practice")
• the "Law of 15-150" limits our ability to interact with other people - the largest network of people who will all trust each other is 15, and the largest number of acquaintances that you can sustain is 150
• "human beings are not like ants" - they make first fit experiential pattern match decisions (not logical ones), they have multiple identities (e.g. father, son, husband, friend, coach), they impute intentionality where none exists, and they have free will
• knowledge spreads by itself in densely connected social networks - so reduce the degrees of separation between teams if you want to create a learning organisation
• managing the economy of knowledge flow (e.g. via mass narrative enquiry) is more effective than trying to manage knowledge itself

I hope that we (as agile practioners concerned with people and their interactions) incorporate some of these ideas and techniques into our work - at an intellectual level at least there seems to be enormous potential for creative fusion.