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.

Must control raging fist of death (he says)

Alan Francis was in prime ranting form at the bar here at XP2005 last night. He raged variously about baseball cricket, mock objects, people who use words without defining them, the differences between v1 and v2 of the white XP book, and several other things besides. He meant it all in a nice way of course, and it mostly amused Michael Feathers, Dave Hoover, Liz Keogh, Brian Swan, and I. We miss working with you Alan: take care of yourself and your family, 'k?
PS: apparently it was me ranting about "practical" Agile (and what is "impractical" Agile anyway?!) It seems I need to control my own raging fist of death too ;-)

"The Industrial Wilderness"

noun: where students go to find paid programming jobs after they graduate from university (as defined by Werner Wild at XP2005)

An inspirational coach

One man who certainly has courage and does communicate is Mike Hill (formerly at Anarchy Creek Software and now working at Industrial Logic Inc.) I overheard him speaking to his tutorial group while they sat on the lawn, and I really valued what he had to say and how he said it:

• XP is a set of values and practices designed to create an effective software development community
• some programmers are still at the magical incantation stage of programming: they need effective teaching in their craft
• I used to believe that some programmers really were dead wood but now I believe that the wood isn't dead, just waiting for spring to come

That last phrase is especially evocative, and I can really imagine Mike bringing spring – light, life and growth – to the teams that he coaches.

The courage to communicate

Diana Larsen's tutorial at XP2005 focussed on three important aspects of teamwork that are often overlooked: listening, decision making, and personal feedback. People can be dismissive of the need to pay attention to these areas, but there is real value to be gained here:

• people who feel listened to are more likely to think creatively and are more likely to become fully involved in a team's activities and goals
• finding occasions to use decision making mechanisms other than concensus (which is the default mechanism for many teams) saves time and effort
• seeking and giving personal feedback influences personal behaviour and therefore directly affects a team's effectiveness

Expressing Business Rules

I arrived at XP2005 yesterday to take advantage of the tutorial track that takes place before the "proper" conference gets under way, and I'm glad I did. Rick Mugridge's tutorial on Expressing business rules with story tests was well worth getting out of bed for early on a Saturday morning. As well as covering the basics - what is a business rule? what is a story test? what is Fit? why use FitLibrary? - Rick also passed on some observations on his experience of using story tests in Agile software development:

• Story tests are as much a communication mechanism as a test mechanism
• It takes both analysis (formalising the business rules for the system) and synthesis (considering the impact on the business of the system) to create good story tests
• The language used in story tests (close to Eric Evans' idea of a ubiquitous language) needs to be open to change, e.g. when understanding or business circumstances change
• Copy and paste between story tests is the sign of a missed abstraction
• Treat tests in the same way as you would code: pay attention to naming tests and refactoring them
• Procedural story tests can often be expressed more clearly and succinctly as a set of declarative tests
• Testing a system through the UI is not the same as testing the UI or testing the system

Three Human Imperatives / Universals

David Cooperrider, the founder of Appreciative Inquiry, identifies these three basic needs:

• To have a voice and be heard
• To be viewed as essential to the group
• To be seen as unique and exceptional

I believe that Agile software teams create an environment where these needs are more likely to be met. What do you think?

Appreciative Inquiry course, day three

The first two days of the AI course I'm attending were a whistle-stop tour through the field using a mixture of practice and theory. This third day was different, much more of an examination of the values of AI and how they can be applied in everyday work situations to reframe "deficit-oriented" questions within this "strength-oriented" approach. (The theory behind why these reframings are so effective is social constructionism, which stresses that "we see what we describe rather than describing what we see".)
In one exercise we tried to write a pithy explanation of exactly what AI is. We came up with these words (my editing):
Appreciative Inquiry is a process and philosophy for personal and organisational growth, underpinned by research in the fields of social and behavioural psychology. It allows us to understand more about what we do by asking about how things are when they go well, and what might be possible if we did more of those things, more often. What's special about AI is the way
it connects respectfully with peoples' hopes and dreams to unleash a positive and creative energy for change.

Some provocative propositions for software development teams

I recently spent some time determining "provocative propositions" about software development teams as part of the Appreciative Inquiry course that I am attending. These statements reflect the best aspects of all the teams I have experienced, described as if they are happening here and now.

• We celebrate what we create
• We congratulate ourselves and each other
• We work together
• We know we can find solutions to our puzzles
• We have fun
• We taste the fruit of our labour
• Our team has a shared heart
• People want to use our great computer systems
• Our great computer systems provide real benefit
• We look forward to doing more of this work tomorrow

Just writing that down feels very inspirational to me - how does it feel to read it?

Appreciating and Inquiring

As I write this I'm sitting outside in the sunshine on the south bank of the Thames. It's not one of my usual haunts, and this isn't one of my usual days: today I'm attending the first of five one-day workshops on Appreciative Inquiry run by Anne Radford. The course was recommended to me by Diana Larsen and the subject is one that I'm becoming increasingly interested in. I first learnt about AI at the retrospectives gathering in February, and I experienced the positive power of AI interviews in Boston last month, so I'm excited to learn more about this technique and how it might be applied effectively with software development teams. Watch this space!

Excuse me while I feel about that for a moment

Dave Hoover is creating and collating Apprenticeship Patterns for software development. I don't want to discount the material gathered so far, it's just that I feel that something is missing. The current set of patterns seem to emphasise developing abstract and logical thought over developing an ability to work collaboratively with people. This doesn't fit with my experience that most of the problems with software projects are in fact people problems and not software problems. (How many "masters" would point that out to their "apprentices" I wonder?)
At the AYE conference last year, Dave and I found that we shared the same NF temperament, one that is quite different to the NT temperament more common in software developers. On the basis of this common ground I therefore proposed a "feeling" apprenticeship pattern, which I hope will find its way into the "thinking"-dominated pattern language that Dave is creating...
Feel your feelings: Building software is a creative and therefore emotional act, especially when you're working together with other people. You will feel uncertainty, pressure, disappointment, relief, joy, and a host of other emotions. But when these feelings are stirred what do you do with them? If you try to hide them do they really stay hidden, or do they come out in other ways, e.g. rising to anger or goofing around? Staying aware of your feelings, becoming aware of other people's feelings, and learning to work with emotions instead of ignoring them, will amplify the effectiveness of any skills you learn.
(I also wrote this a slightly different way. Discover yourself while you learn your craft: the journey you take as an apprentice is as much about yourself as is it is about building software. If you have the courage to discover the person behind the personality - what drives your behaviour, how it is perceived by others, and why that might be - then you will amplify the effectiveness of any skills you learn).

The framework you want is not what you think it is

In an interview on Artima.com Erich Gamma says: Well yes, I matured too and XP reminds us that it is expensive to speculate about flexibility, so I probably wouldn't write this exactly this way anymore. To add flexibility, you really have to be able to justify it by a requirement. If you don't have a requirement up front, then I wouldn't put a hook for flexibility in my system up front.
I've worked with several teams who wanted to add all kinds of hooks today for flexibility that might only pay off tomorrow. This may be a symptom of having been burnt by changing requirements in the past, a response to blame that says "Well they said it should have been more flexible!" Or it may signal a lack of comfort in the whole incremental delivery model that underpins Agile software development.
One team I can think of wanted to put off writing all the customer specific code until after they had written a flexible framework for the application. Did they really want to write a framework? Probably not. The team were really quite committed to delivering something valuable to the customer, they just felt they needed to spend a lot of time creating loosely coupled abstract base classes in order to do this. My job was to show them that the framework they thought they wanted was really just a design that could be allowed to emerge.
As Erich puts it: Frameworkitis is the disease that a framework wants to do too much for you or it does it in a way that you don't want but you can't change it. It's fun to get all this functionality for free, but it hurts when the free functionality gets in the way. But you are now tied into the framework. To get the desired behavior you start to fight against the framework. And at this point you often start to lose, because it's difficult to bend the framework in a direction it didn't anticipate.

Fault finding obscures the real problems

Asking effective questions is often helpful, but today I had an experience where this approach wasn't getting me anywhere. In fact, the problem was that I was asking questions at all.
In the old way of doing things the software may have been late or poor quality or lacking in features but the customer could be clear that this was the "development team's fault" (in some vague, arm's length kind of way). But now the development team are starting to work more closely with the customer this excuse for the product's problems disappears. In fact the original finger of blame might conveniently have been hiding a very different problem indeed.
The development team have asked for a single voice to provide priorities and direction, and the customer who could provide that voice is finding that they represent a diverse user base whose different priorities are intrinsically hard to balance. No wonder this question is so difficult to answer:
Can you help me to understand if meeting the original deadline is less important than having this additional functionality or are there some features we can defer in order to meet the deadline?

Just what is it you want to do?

Alan Francis innocently put this question to me in an email and it really got me thinking. The sentence that eventually cohered in my head was this:

I'd like to help people open their eyes to ways in which we can work more collaboratively with each other as human beings to create better software.

That could take some time.

(I might also be tempted to say "I want to get loaded and I want to have a good time" but that would of course just be the music talking...)