Goodbye England, hello Canada!

I've recently moved with my family to Ottawa, Canada. There were a slew of reasons for doing so but the principal ones were the amount of travel I was doing for work - which took me away from my home and family too often - and the fact as an independent consultant I saw lots of "beginnings" - helping teams to start down the road to Agility - but felt I was missing out on the bigger picture: I want to go back "inside an organisation" and coach teams and individuals over a longer period than a consulting gig allows.

It was a slog getting everything packed up before we left - although we allowed plenty of time for it, the work definitely seemed to expand to fill the hours available - and after we arrived I couldn't remember precisely which items had come with us on the plane rather than being packed into boxes to follow by sea. So I wasn't quite sure what to expect when I opened the work-related folder I had packed into my suitcase. This is what I found: one copy of Kent Beck's XP Explained (2nd edition); one printout of Martin Fowler's article The New Methodology dated December 2000; printouts of Alistair Cockburn's articles Characterizing people as non-linear, first-order components in software development and Software development as a cooperative game dated March 2001; my most recent notebook; a few index cards; and a small packet of coloured "sticky dots".
Which made me think about why I had selected these particular things (ignoring the notebook and index cards which get stuffed into a bag to go with me pretty much everywhere), especially since I probably packed them "on autopilot". Well, Kent's book is pretty much a no-brainer: it's small, the XP values and principles resonate deeply with me and I frequently find myself dipping into it. The article printouts were probably selected on the basis of their dates (although they remain a good read): they have sentimental value from back when I started applying an Agile approach to my own projects, and remind me of the wonderful people I got to meet in London through the Extreme Tuesday club and Thoughtworks. Which leaves the "sticky dots": I think I must have thrown them in as props to represent the kind of facilitative role I enjoy taking as a coach and which I've learned so much about through the retrospectives community.
Here's hoping that I find the kind of work I'm looking for!

Our most important project

I've had a couple of experiences with introducing Agile on "our most important project", and they've been both a fascinating mix of a genuine desire to run the project differently (to avoid past problems) and the fear of introducing risks by changing the status quo. As Tom De Marco says in a lovely line in Peopleware: People don't like change. I'll say that again - people don't like change..
So what to do?
First let's take a moment to put ourselves in the project team's shoes, and appreciate how profoundly scary it can be to work on a high-profile project, with all the weight of expectation and oversight it entails. Because on top of all the existing pressure on people we're adding the burden of learning to do things in a different way (which may be overwhelming), and removing the comforting thought that "it's ok, we've done this before". On what basis can we be confident that this is the right team, the right project, and the right time to introduce change?
Second let's stop and think about ourselves a little. Do we have the support inside (and outside) the organisation that we need? Are we in the right state of mind to cope with actual or potential failure, and any nay-sayers who might try to shoot us down or the ideas we espouse? (An early "thanks, but no thanks" to the engagement may save a lot of pain later on...)
Assuming we believe that everyone is prepared for the challenge then I'd argue that the final thing to do is to seek out and connect with the positive drivers for change that already exist. Approaches such as Appreciative Inquiry should allow us to envision this project's future (Agile) success and tie it together with those past times when things have gone well. But if we can't, then perhaps that is the strongest possible signal that "our most important project" should be run in the same way as usual.

Communication, communication, communication

I believe that software development is for the most part a social activity. This implies that in many circumstances the most valuable work that a coach can do is to improve the quality of interactions between people in a team (especially when the individuals that the team will be made up of is not a variable that can be influenced.)
So I often find myself reflecting on the quality, frequency and modes of communication that I observe: trying to understand why a particular phrase is used or stance is taken. (Which also involves wondering about the things that are not explicitly discussed as well as the things that are.) And quite often in teams that are struggling there seems to be a lot of miscommunication that only serves to perpetuate the problems that the team is struggling with.
Barry Oshry's work on the way that people make up stories to explain what they don't understand - reframing other's motivations or intent to place them within their own perspective - has been exceptionally helpful for me in making sense of such situations, and the application of Virgina Satir's coping model in organisations has also provided useful insights.
Sometimes however there seems to be a repetitive cycle of miscommunication between particular individuals whose dynamic seems to fit more with the ideas of Games People Play and the roles of Persecutor, Rescuer and Victim in the Karpman Drama Triangle. While it helps to have some awareness of what might be going on in these circumstances, I find such situations quite stressful. It is tempting (for my ego!) to try and play the part of "the hero" who can "save" the team, but I recognise that by doing so I would leave people stuck in the same disempowered situation as they were before I joined them. Which is not what I believe an Agile coach should do.

Learning from experience

As a long-time advocate of retrospectives, one of the most rewarding parts of the teacher training course was seeing the idea of "learning from experience" in a different context. A large part of the art of teaching is actually about encouraging learning: moving beyond the transmission of knowledge and practical skills so that pupils develop their own "metacognitive ability", identifying the ways in which they learn and reflecting on their own thought processes in the light of experience. (Happily trainee teachers are also expected to do the same and become Reflective Practitioners through a mixture of self-evaluation and mentoring).
Learning to Learn seems to be a fairly hot topic in educational research, and in my reading around it I often found successful learners described in terms such as "resilient", "resourceful", and "reflective" (definitely attributes I have seen in the most successful software teams, and the individuals within them). It was extremely rewarding as well to read Papert's book "The Children's Machine", whose emphasis on how we learn through exploration – reaching conclusions about abstract concepts through progressive, concrete experience – resonated with so much of the debate in software circles about emergent design.
Back in the business world, people like Senge have been popularising the idea of learning organisations for a long time. So why do software teams, even Agile ones, often see (or gain) so little value from retrospectives? Are the retrospectives not being done "right"? Do teams see the retrospective event as the only time to reflect so that they miss the learning opportunities that crop up more frequently? Or are there so many limits to what people are "allowed" to question and change within their organisation that they simply give up on the whole idea of trying to learn and improve...?

Arriving back at the beginning...

As T.S. Eliot wrote:
the end of all our exploring
Will be to arrive where we started
And know the place for the first time.

I'm back at the code-face again: working as an Agile Coach with software teams. It's an interesting experience: I feel that my time away has helped me see the challenges and pressures of project delivery more clearly (such as tight schedules without clear priorities, restrictive budgetary rules that confuse “cost” with “value”, and management / reporting structures that reinforce divisions between groups instead of opening up communication and collaboration between the individuals that need to work together to achieve the desired results.) Perhaps as an outsider – a consultant – I have a privileged viewpoint, though I don't really buy that argument. People within the teams I work with often describe the problems they have in terms of the complex, systemic interactions within their organisation: problems that require more than a simple “fix” to one activity (or even, shudder, one person) in isolation.

Moving on, moving out

After 14 years working as a software developer and with software development teams I've decided to try something completely different: I'm now training as a secondary school ICT teacher in the UK (ages 11-18) and I won't be posting here any more...

Why might you think otherwise?

Having to work harder and act like 'robots', with little scope for personal initiative, are the chief reasons for declining job satisfaction in Britain, according to a new study.
Feelings of insecurity, too high expectations and people being 'over-educated' and unable to find work to match their qualifications, are largely dismissed, in the study led by Professor Francis Green of the University of Kent. His team found no evidence to back suggestions that the dull mood of workers may be due to successive generations having ever higher expectations from their jobs and being disappointed by the realities of employment.
Tim Osborn-Jones at Henley Management College said: “Employee commitment is known to be important but complex. Staff that 'want' to stay are likely to go the extra mile to achieve an exceptional outcome. Staff driven more by a 'need' to stay (lack of alternatives), or sense of 'ought' to stay, may be less concerned with outcomes.
"Henley's own research also suggests that, even in today's downsized, de-layered organisational world, most talented individuals want an employment relationship based on trust, social exchange, and will engage when given the opportunity to achieve self-fulfilment, a sense of accomplishment and fun and enjoyment at work."

Retronyms

A retronym is a word invented in the present to describe something that needed no definition in the past. (For example the "acoustic guitar" is a retronym that was only needed after the electric guitar was invented.) What retronyms might there be for the Fragile software processes that previously had no name:

• Blame oriented software engineering?
• Just too late software production?
• Document driven design?
• Test last and hope development?

(With thanks to Conan Dalton for starting this discussion at XP2005...)

Announcing "Experiences": an e-zine for software practitioners

Story-telling is a long-established human activity with a rich and diverse history. Today the power of story-telling is applied in software development teams through retrospectives, appreciative inquiry, narrative therapy, and cynefin techniques, as well as around the water cooler. Stories help us to understand, question, and inform the way we practice our craft. (Think for example of the way that the story of the C3 project was woven in to the early XP movement.)
It struck me a while ago that the only stories that software practitioners tend to share in print are 'headline' stories: bigger, bolder and more in-your-face than many of us might relate to. Where are the everyday stories of 'aha' moments, hopes and disappointments, and tales from the code face? There are plenty of these in blogs – one of the reasons why the blogging medium is so popular, I think – but no collections publishing a variety of voices in one place.
Or at least there were no such collections until Joel Spolsky put together Best Software Writing.
There are plenty more interesting and informative stories not in that book, and the number of those unheard stories increases every day. So I wondered to myself, why not seek out more stories and make them available electronically? Which is what I intend to do: this is the official announcement of the launch of the grass roots e-zine Experiences, that will collect stories from software practitioners and share them in the community.
My vision is that this e-zine becomes a collaborative endeavour, "published" three to four times a year, with varying editors, themes and contributors. For the first edition I'm looking for descriptions around 500 words long of events that actually happened to you, with or without an explicit commentary or lessons learnt section. Preference will be given to European contributors providing original (unpublished) material covered by a Creative Commons license. The target audience is software practitioners and consultants working in Europe, but stories don't have to be limited to the realm of software development. If you'd like to contribute or have any questions or observations then I'd love to hear from you! Here's hoping for a great launch issue in August...

Wrapping up with Kent at XP2005

The end of the conference featured Kent Beck, twice. First he joined a panel discussion on Leadership (summarised here by Steve Freeman, and from which I took away the strong conclusion that leadership starts with holding one's own congruent stance in the face of resistance and then pulls others in to acting congruently as well). Then he had the stage to himself for the keynote speech, entitled Another notch. It addressed in a wide-ranging way the possibilities opened up by embedding the values of XP in an organisation's culture and philosophy, a theme that seemed to be bubbling under many of the sessions in the conference.
Initially Kent pursued the idea that XP is bigger than mere practices, that "technical success is not success", and that all the best TDD and refactoring and continuous integration in the world won't matter if a project fails to meet the needs and timetables of its sponsors and users. "Typing in a line of code has consequences" he said, and those consequences are part of a larger world-view that needs to be embraced if XP is to move up another notch. Is programming really the best focus of all of our energy? Perhaps the application of the technical processes described in the first edition of the white XP book has moved project constraints away from programming to a different aspect of the development process? (The theory of constraints shows that micro-optimisation of one step in a complex process can in fact degrade the throughput of the process as a whole.) There might be a lot of other non-programming tasks that can be done right now to eliminate the constraints in the wider team, department or organisation: "it's a fiction to believe that if I get all my tests green then the project's ok and I've done my part" as he put it.
The next part of the speech was a request for the XP community to take accountability - "rendering an account of your actions to others" - more seriously. Accountability is a synonym for fault in blame-ridden organisations, but this is not its real meaning. To hold myself accountable is to be proud, honest and open about what I do, to live the values I espouse. To "overcome the disconnect between the satisfaction I get from programming and the dissatisfaction I get from life". To understand that I can't really change my organisation, and I can really change myself. To cope with the realisation that enacting the transition to XP requires respect for the starting point, and is "more than saying everything will work out if everyone does as I say". (At which point Kent started praising the approach taken by Appreciative Inquiry, which was nice...)
He wrapped up by sketching out his vision for what will happen as XP is taken up another notch. People and projects will be truly accountable and have nothing to hide. Teams and individuals will express their XP values in all their actions and interactions. The confidence to hold onto ones self in the face of pressure will engender trust, creativity and learning. And as a happy side effect software projects will get delivered quickly and at high levels of quality too.
I'll sign up to that.