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.

The Drawing Carousel

I heard good reports about this workshop when it was run at the 2004 XPDays and I wasn't disappointed at XP2005. Vera Peeters used the analogy of a group collaborating on a drawing to guide 8-person teams through an exploration of what pair programming is about. From the perspective of someone who has experienced pair programming teams already I think that I mostly had fun (!), observed some forming, storming, and norming close up, and got a better idea of the perils of ignoring what you know to be "right" (e.g. integrating early and often, reflecting on and adjusting your process) just because the customer starts with a different perspective to your own.

Workshops that I co-facilitated at XP2005

On Tuesday I co-facilitated two workshops, exploring Informative workspaces with Rachel Davies in the morning, and Teamwork and team working with Dave Hoover in the afternoon.
The morning session was well attended and generated a number of anecdotes about the elements of an informative workspace, from which some themes emerged (see photo on left). Sadly, the subgroups that explored a few of these themes expressed concern about how others in the organisation might misinterpret or misrepresent an informative workspace. Perhaps this is a recognition that, as Kent Beck said, if your organization punishes honest communications and you start to communicate honestly, you'll be destroyed. (The workshop also uncovered other - more uplifting! - aspects of informative workspaces that I hope will be summarised more formally in the future.) Thank you Rachel for inviting me to join your session - it was great to be a part of it.
The afternoon session was less well attended, which surprised me as "people and teams" seemed to be a fairly popular topic of conversation in the bar. (Note to self: more flagrant self-promotion next time!) The workshop content and approach altered a fair amount between the time of the submission process and my arrival in Sheffield, reflecting my own recent professional wanderings via AYE, much introspection and some meditation, a very challenging coaching engagement, and an exploration of the social constructionism themes underlying both narrative therapy and appreciative inquiry. The end result was a workshop focussed mainly on the ways that team dynamics can be understood through the thought processes of the team members themselves. (If you're interested then the handouts from the workshop are available online.) Thanks to those who expressed some interest in what was discussed after the workshop, and I hope that attending helps you in your work teams.
All in all it was a busy day, and I was glad that I had prepared for it by making the time for a refreshing early morning run along the nearby gritstone edge at Burbage. If you attended either of the sessions and have some feedback on your experience, then I'd love to hear it.

Agility - Coming of Age

Jutta Eckstein gave one of the invited talks at XP2005, reflecting on the change in her consulting experiences as Agile software development reaches out across the chasm to the early majority. She said that she is no longer coming in midway through "projects in crisis" (for whom an Agile approach is "a last hope") but is instead being invited in to the earliest stages of projects that have enthusiastically chosen to start with an Agile software development process. (She noted that the official German government methodology has changed to incorporate some Agile ideas, such as mandatory continuous customer involvement throughout the life of a project.) Jutta described some of the challenges of being a consultant involved in these different kinds of projects (e.g. how much experience / research did the customer have when deciding to use Agile? what are the Agile solutions appropriate to very large distributed teams, or those creating hardware as well as software?) and she stated that overcoming these is preferable to the ill health she suffered through her involvement with past unhealthy and suffering projects.
I can relate to that myself: I've seen good Agile consultants burn out on "rescue missions" that provided props for an organisational system whose actions created the need for a rescue in the first place. And Jutta addressed this topic of the organisational system directly, asking: is it possible to run a sustainable Agile project within an organisation whose values, expressed in words and deeds, are not aligned with the Agile manifesto? And I agree with her: using Agile is about more than applying a set of practices - the actual practices in use can (and should?) differ from one Agile project to another - it is about working within a value system.
Jutta finished with two provocative comments. Firstly she said that Agile isn't "trendy" anymore, so if you're looking for the cutting edge and the next big thing then now is the time to move on and find it. Then she finished by saying that any team not holding retrospectives isn't doing XP (yay! more retrospectives!! spontaneous applause from Diana Larsen!!!). All in all it was a stimulating talk, and it prompted a lot of conversation in the bar afterwards...

My son has chicken pox

And I'm at XP2005, unable to comfort him or offer support to my wife. The conference and all its attractions somehow seem less relevant right now, and my thoughts are elsewhere. Get well soon Lucien...

XP2005 - the Toyota way

Pascal Van Cauwenberghe and Marc Evers ran an interesting workshop based around the ideas in the book The Toyota Way (Author Jeffrey Liker, ISBN 0071392319*). The attraction of studying Toyota is that the company's success in the mature car industry points to a tried and tested lean approach that evidently scales up well, has lessons to teach other industries such as software, and that can easily be brought up in conversations with "men in ties" executives.
What I got most out of the workshop was an appreciation of how deeply long-term thinking is embedded in the Toyota culture, and a feeling for the very rich interrelationships between the 14 principles (much like the interrelationships between barriers, attractors and probes described in the Cynefin approach).
Among the group the topic that probably generated the most discussion was the idea of a company's long-term philosophy: does your company have one, do people know what it is, and is it visible in the company's actions and intentions?
* Tom Poppendieck also recommended the book Product Development for the Lean Enterprise to people who wanted to understand more how the lessons of Toyota might apply to the software industry.