coachspot

Goodbye England, hello Canada!

2009-05-23T07:41:00.000-04:00

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

2007-07-16T03:13:00.001-04:00

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

2007-05-14T07:15:00.004-04:00

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

2007-04-30T10:54:00.000-04:00

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...

2007-03-09T09:51:00.001-05:00

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

2006-08-12T12:45:00.001-04:00

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?

2005-07-06T04:24:00.000-04:00

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

2005-07-06T04:20:00.000-04:00

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

2005-07-05T04:26:00.000-04:00

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

2005-06-24T15:59:00.000-04:00

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

2005-06-23T15:27:00.000-04:00

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

2005-06-22T15:52:00.000-04:00

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

2005-06-21T17:11:00.000-04:00

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

2005-06-21T17:04:00.000-04:00

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

2005-06-21T16:32:00.000-04:00

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)

2005-06-20T08:45:00.000-04:00

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"

2005-06-19T13:11:00.000-04:00

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

An inspirational coach

2005-06-19T13:08:00.000-04:00

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

2005-06-19T13:05:00.000-04:00

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

2005-06-19T12:07:00.000-04:00

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

2005-06-19T12:01:00.000-04:00

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

2005-06-17T16:51:00.000-04:00

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

2005-06-12T07:22:00.000-04:00

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

2005-06-09T18:07:00.000-04:00

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

2005-06-06T17:52:00.000-04:00

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

2005-06-06T16:57:00.000-04:00

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

2005-06-01T19:03:00.000-04:00

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?

2005-06-01T17:31:00.001-04:00

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...)

XP2005 gets closer

2005-05-26T17:07:00.000-04:00

Dave Hoover and I are presenting a workshop at XP2005 next month. Today I received a timely reminder that the date isn't so far off, thanks to this email from the publisher of the conference proceedings: We are very pleased to be the first to congratulate you on the electronic publication of your article 'When Teamwork Isn't Working' published in 'Lecture Notes in Computer Science'.
I hope I'll be seeing you in Sheffield in three weeks' time!

Scrum Gathering, Boston

2005-05-25T17:40:00.000-04:00

The Scrum gathering in Boston took place over 3 days: a more introductory one day public session followed by two days of discussion workshops for experienced Agile practioners. On the first day I was thrilled to be asked to join Jeff McKenna and Diana Larsen on a panel discussing change.
Change was a good discussion topic for the gathering because of the paradox that so many people in our industry face: we are software development practioners not change agents, yet to develop software better we desire to change the organisations we work in.
While I am no expert in Organisational Development I do know that all the effective teams I have been part of - mostly Agile teams - became what they were through a process of positive change. (And in some instances - I am proud to say - change that I directly facilitated.)
Can we achieve positive change, starting from where we are, no matter how "low" our position is in the organisation? Absolutely! All changes start with ourselves - Be the change you want to see as Gandhi said - and when "They" seem to be part of the problem then changing our own viewpoint is always the start of a solution. (We may not always be aware of the positive effects that our new viewpoint or behaviour has, and the changes we set in motion may take longer to ripple out than we have the patience to hang around for, but they will still be there and others will still see them...)
The workshop group that I was part of in the 2nd and 3rd days - with Bill Wake, Marilyn Lamoreux, Dan Rawsthorne, Kate van Buren and others - used Appreciative Inquiry interviews to explore aspects of the change and transformation that Agile teams go through. The coaching and leadership role provided by a good Scrum master during this change was of particular interest to me, and we came up with these words to describe it (my editing):
An effective Scrum master facilitates the transition from a group of individuals into a team. This transition starts with the Scrum master acting as a role model and offering inspiration, and is completed by the team members themselves with their reflection, open communication, and a desire to turn new-found awareness into action. Through this cycle of self-actualisation teams create a more effective future where they can enjoy their work, honour their successes without bemoaning their failures, and collaborate more productively.
While this may sound as though change requires the intervention of an outside person, I don't accept that this is the only interpretation. At the level I have most experience working at - with individuals in a single team - I see the changes required to introduce Agile software development mostly in terms of uncovering more of what is already there. Achieving lasting personal growth by fulfilling a potential that has been unseen but that is ready and waiting to be unleashed.
So if you can see that potential within your team then you can start growing it yourself, today.

Retrospective facilitators gathering 2005

2005-05-24T17:14:00.000-04:00

I can still feel the energy and insights I gained at the retrospectives facilitators gathering, even though it happened back in February. The gathering was run at a retreat in the desert outside Phoenix, and the whole event was organised as an Open Space, creating so many stimulating and informative discussions that it was impossible to keep up with all of them. I learned a lot, some of it about: facilitation, thinking about puzzles, the Zeigarnik effect, dealing with curve balls, the power of story-telling, “moments of madness”, ORID techniques, “explorers, shoppers, vacationers, and prisoners”, the Art of Possibility and self-fulfilling prophecies, celebrating what's right with the world, and appreciative inquiry. Phew!
I was delighted to be able to attend the gathering and touched by the warmth and openness of all the wonderful people I met in Phoenix: people like Linda Rising and her husband who showed me such incredible hospitality, Boris Gloger whose wicked sense of humour is so endearing, Jean Tabaka who was such good company, Norm Kerth whose work created the retrospectives movement, Heather Nelson who asked the difficult questions that only a talented PhD student can, Pam Rostal whose inspiration has had such an effect on her students, III whose deep voice matches his deep insight, and many others. (Plus the wonderful people who were also there that I knew from other occasions, such as Esther Derby, Diana Larsen, Rachel Davies, John Suzuki, Laurent Bossavit, Tim Mackinnon and Richard Watt...)
I have no doubt that retrospectives are an effective tool for increasing productivity and quality in software development teams. Better yet they can be a vehicle for introducing communication, interaction and humanity back into our workplaces... and that can't be bad.

A brief look backwards

2005-05-23T03:22:00.000-04:00

So, what was I up to these last few months when I wasn't blogging regularly? Quite a few things really:

in January I took the certified Scrum master course with Ken Schwaber (organised by Conchango)
I attended the Retrospectives facilitators' gathering in Phoenix in February
in March I went skiing for the first time with my family
just a week or so ago I was a panellist at the Boston Scrum gathering
and mostly I have been coaching a couple of banking teams towards adopting Agile software development

Each of these came with its own rewards and challenges. I'll be posting briefly about all of them, starting here with the one that took the most effort: the coaching.
The coaching engagement was hard work for a variety of reasons. For example: there was a fragile legacy code base to deal with; the transition to an Agile way of working was imposed not chosen; several developers were unfamiliar with the chosen programming language; a succession of team leads had created a strong hero culture; the team were unfamiliar with negotiation and collaboration; managers were conditioned to blame avoidance; and customers were used to communication that was infrequent or even misleading.
I guess you could say that these teams were not the ideal candidates for an Agile transition, but you have to start where you are and with what you have. By the end of the engagement the teams had successfully adopted an iterative style of working, learned to write unit and acceptance tests (and appreciate having them!), and were conversing more constructively with their customers and users.
All of this made me feel that the hard work was worthwhile, though I wonder how durable the changes that I saw really are. Much of the time I felt that I was pushing against the culture of the organisation, and I suspect that over time those strong organisational and cultural forces will push the teams back to a place similar to where they started. But I hope not.

Where does the time go?

2005-05-17T02:00:00.000-04:00

It's hard to believe that over two months have passed since I last posted here. I certainly haven't run out of things to write about, and while it's true that I have been busy, I haven't been that busy. Actually I was probably busier back when I was posting regularly. Somewhere along the line I let go of my rhythm.
Rhythm can play an important and often undervalued part in our lives. It sustains our ability to do more in less time and with less effort, and allows us to do what we do more efficiently. It's one of the reasons why teams working iteratively can work harder than teams that don't. (Incidentally, rhythm is not the same as routine though the two are obviously related: a sluggish but regular routine lacks rhythm, for example).
So, the lesson I take away from this is that when you find a good rhythm then it pays to maintain it. In my experience it takes longer to get back into the swing of things than it does to fall out of step.
Postscript: I think that Esther Derby has a good explanation for why I lost my rhythm. I certainly went through a "whining about my problems to other people" phase when I could have been more productively "writing down what I was seeing and interpreting it the next morning in the light of day"...

[grid::fatherhood] (sort of)

2005-02-25T17:04:00.000-05:00

Two ways of saying the same thing?

Not surprisingly, there are plenty of reasons for male hesitation when it comes to committing to partnering and parenthood. (Via Alan Francis)
You know what? Boo [censored] hoo. Being a parent means, to some extent, suppressing your personal needs, desires, and expression for the good of your children. That’s pretty much A-number-one on the list of job requirements... Your child is not perfect. Parenthood is not a sun-filled meadow of joy. Raising children is not easy, and it isn’t a smooth ride, and you aren’t going to make the best decision every time. There are diapers to change, mouths to feed, tantrums to weather, and sleepless nights to endure. You don’t get to be yourself any more, not completely. Not the way you used to before the baby. That isn’t how it works. Furthermore, you are not uniquely suffering, because this is how it’s been since humanity became sentient, and definitely how it’s been since civilization emerged. So deal with it. (From Eric Meyer)

Recruitment and Retention

2005-02-10T03:45:00.000-05:00

There seems to be a lot of interest in recruitment practices for Agile teams, but I have heard much less about the retention practices thereafter. This is perhaps understandable given that recruitment is explicit and visible, and retention is not (both in terms of the time and money required). But retaining skilled Agile staff is just as important as recruiting them in the first place, and is probably harder to do*.
So how much attention do Agile organisations need to give to retention? Obviously it becomes a higher priority when the job market is buoyant (as it has become in the UK in the last six months), if only because of the personnel agencies whose financial wellbeing depends on persuading staff to change jobs fairly frequently. But in general what are the factors to consider?
Well, Agile team members seem to be happier on the whole (i.e. less likely to leave), and Agile teams are certainly less dependent on any single person because of the way that knowledge is shared around. But on the other hand, because Agile teams can be so "close knit", one person leaving an Agile team can create a “diaspora” effect: others in the team start to change their employer not because the present one is especially bad, but because they value continuing to work with the people they work well with.
Perhaps there is a real financial risk to Agile projects that pay only lip service to retention, whose team members will be at least as loyal to each other as they to are to a employer?
Afterword: this post was stimulated by the rising number of ex-ThoughtWorks staff now working at the same London investment bank. (And yes, I am one of them.)

* I say retention is harder because it requires a continual effort to understand people as individuals – what they find motivating or threatening, what growth paths are open to them and so on, all of which will change – and an organisational structure that is adaptable enough to meet (and keep on meeting) a wide range of sometimes contradictory wants and needs. Whereas recruitment (even recruitment for Agile teams) is often reduced to a process that requires little or no organisational commitment.

Uncovering Coaching Stories

2005-01-24T13:21:00.000-05:00

I started coaching a new team recently. Before taking on the role I went through a useful exercise to “uncover the coaching stories”*. The aim is to understand why a potential customer thinks that they need a coach (or more usually, why they think that they need an Agile process because they want a coach to help them introduce it).
By exploring the answers to questions such as:

What is the problem?
How does the problem manifest itself?
Who wants a solution?
How will we know that the problem has been solved?

the customer and I start to get a feel for how difficult the engagment is, how much organisational support for change there is, and (crucially) whether we will be comfortable working together.
Although I find this useful I don't claim that it is a unique approach: Jerry Weinberg's consulting books were my original inspiration, and I heard from Andy Pols that Alistair Cockburn also interviews his prospective clients (in his case as a client selection process as well as an information gathering exercise).
Reflection:Would this approach work for you? How could you find out?

* Keith Braithwaite and I touched on coaching stories in a presentation we gave back in 2002. The basic idea is that customers have stories for a coach just as they have stories for a development team, although the scope and nature of coaching stories are typically very different from development stories.

The Consultants Calling: Bringing Who You Are To What You do

2005-01-10T14:31:00.000-05:00

Geoffrey Bellman's book is superb, and deserves a wider audience than the title might suggest. It is “about consulting” in the same way that Shakespeare's Hamlet is “about Denmark”: the scenes are set in the world of consulting but the message is more widely applicable. The twenty or so chapters describe how work becomes more rewarding, and how we become more effective at doing it, when we treat it as a human activity (not a financial transaction), and one that reflects our own human needs, desires, and failings.
Congruence, integrity, love, fear, boundaries, power, money, and transformational change are all discussed in the context of organisations and the people who work in them. Reading it challenges us to look deeply at ourselves, to understand what we want from our work, and to consider whether we are bringing ourselves to what we do, or acting out a role.
It's not often that I write a review of something I've read (it's certainly been a long time since the last one!) but I found this book special and can strongly recommend it.

Ubuntu

2005-01-05T04:31:00.000-05:00

The recent Debian-based Linux distro Ubuntu has been getting good reviews. The name is an intriguing one: according to their home page "Ubuntu" is an ancient African word, meaning "humanity to others". Ubuntu also means "I am what I am because of who we all are". According to Linux User & Developer magazine Archibishop Desmond Tutu (Nobel Peace Prize laureate) said: A person with Ubuntu is open and available to others, affirming of others, does not feel threatened that others are able and good, for he or she has a proper self-assurance that comes from knowing that he or she belongs in a greater whole and is diminished when others are humiliated or diminished, when others are tortured or oppressed.
What is the relationship between software development and Ubuntu? Because I feel that software development is essentially a human activity I believe that having more Ubuntu in yourself increases your capacity to be an inspirational coach or mentor, and having more Ubuntu in your team increases your capacity to collaborate in creating great software. I'll be revisiting this theme in my next post: a review of Geoffrey Bellman's excellent book The Consultant's Calling: Bringing Who You Are to What You Do.

The end of 2004 - part 2

2004-12-31T15:38:00.000-05:00

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

2004-12-31T13:19:00.000-05:00

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

2004-12-30T06:20:00.000-05:00

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?

2004-12-22T09:33:00.000-05:00

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

2004-12-20T08:46:00.000-05:00

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

2004-12-17T20:13:00.000-05:00

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?

2004-12-17T17:22:00.000-05:00

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

2004-12-14T14:30:00.000-05:00

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

2004-12-14T09:23:00.000-05:00

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

2004-12-06T10:03:00.000-05:00

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

2004-12-06T06:50:00.000-05:00

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

2004-12-06T05:35:00.000-05:00

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

2004-12-05T17:29:00.000-05:00

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.

Introducing new ideas

2004-11-21T08:45:00.000-05:00

One of the nicest things at AYE was a complete surprise: actually seeing a copy of the much-anticipated book "Fearless Change: patterns for introducing new ideas" (by Mary Lynn Manns and Linda Rising). It's full of illuminating ideas and contains strategies applicable in many project situations. (An overview of the material was presented at XP2004 and you can see the slides online.)

NB: Harvard Business School Working Knowledge recently had these wise words to say about "The challenges of paradigmatic change": Third, be patient and wait until the time is right. Paradigmatic change requires a unique set of conditions. Sometimes, the organization will reject the change several times before a critical mass of managers finally recognizes the need for change and the utility of the new paradigm. Focus on winning the war and not every battle.

AYE afterword

2004-11-20T09:24:00.000-05:00

AYE was an unusual conference. Hands-on workshops replaced the usual words spoken to a silent audience from a "sage on a stage". Gaining a better awareness of everyday work experiences and feelings was emphasised over learning yet another "silver bullet" tool. The conversations and self-examination that took place over lunch and dinner were as much the point of the conference as the organised sessions. There were plenty of attendees with over a decade of experience who demonstrated that intelligence, curiousity, and capability do not have to diminish after 30 or parenthood. Like I said, as far as my experience goes, AYE was unusual.
I imagine that an older "touchy feely people person" like myself was always going to get more out of AYE. There was plenty of talk of centering, and grounding, and being present in the present: concepts that are perhaps anathema to consultants who see technical answers to all business problems. But, for those who feel that much of software development is not work with computers but with people, there was a lot to take away and digest. Does AYE actually "amplify your effectiveness"? Perhaps. Does AYE provide tools with which you can start to "amplify your effectiveness"? Definitely.
Postscript: check out these pictures taken by Steven Smith at AYE (including one of me!)

AYE (Wednesday)

2004-11-11T09:30:00.000-05:00

Maybe the sessions that I attended on Wednesday appeared to be about recognising and vocalising emotion because I was sad that it was the last day of the conference.
The morning Writers workshop run by Johanna Rothman and Naomi Karten provided a safe environment to share even the most personal writings and feelings; and the afternoon Reflection leading to action session led me to contemplate the emotional responses to AYE that I experienced and want to act upon.
I would like to say a big thank you to the hosts and the other attendees for making it such a great conference: I know that as I go home I am taking a part of AYE with me.

AYE (Tuesday)

2004-11-10T01:20:00.000-05:00

It took me a while to work out what I think that the two sessions that I attended today had in common, but it was probably understanding the reactions of people on the receiving end of change. The morning session was Increasing your effectiveness as a change agent, which converged on the concept of organic change - a low key start with early success that can build into something larger - as a way of avoiding the fear-based defense responses to large, sudden, externally imposed change.
The hows, whens and whys of measuring group dynamics (such as the response to change) was covered in the afternoon session (Non-quantitative metrics, run by Naomi Karten). Both sessions brought home to me just how easy it is to overlook or misunderstand the reaction of an existing team when an external consultant arrives: it has been another very worthwhile day!

AYE Agile BOF

2004-11-09T17:51:00.000-05:00

The "Birds-Of-a-Feather" group to be at on Monday evening was the Agile BOF: a dozen or so of us got together to eat pizza, swap ideas, and discuss what an AYE-Agile attractor might look like. Roughly half of us had actual Agile project experience (or more, if you count years of experience and take Jeff McKenna's into account!), and running the evening as a goldfish bowl panel allowed everyone a chance to contribute to the discussion. Several attendees asked what the clear distinction is between TDD, XP and Agile, but the discussion also wandered into topics such as the difference in team dynamic, technical architecture, and ROI in Agile projects. It was nice to hear the enthusiastic point of views of people that I haven't met before (such as John Brewer), as well as indulging my own passion for evangelising the benefits of Agile methods.

AYE (Monday)

2004-11-08T20:31:00.000-05:00

I attended two sessions today that shared the theme of finding ways to break out from an unproductive way of thinking. The first was Don Gray and Becky Winant's "Making conscious decisions for change", which explored how changing perception leads to changes in behaviour. We discussed mental models (deletion, distortion, construction, generalisation), modalities of thinking, associated and disassociated experience, the interaction between the "here and now" (present) and the "then and there" (past), and creating options through awareness of our assumptions. All of these techniques and concepts provided me with powerful insight into how I might coach teams better through some common project problems.
After lunch Martine Devos and Jerry Weinberg ran a session on Organisational Mapping. This is a technique for exploring the multidimensional complexity ignored in more traditional org charts (such as who has money or budget to spend, where people are located, who communicates with whom, who gets along and who doesn't, etc). Interestingly we found as we drew our own maps that inanimate objects (e.g. story walls) and intangible things (e.g. rumours, or ghosts of previous managers or employees) occupy a place within these maps.
When comparing several maps of the same organisation in an "art show" what was striking was how much they varied, and why. To each individual their map was true. Taken together (especially taking the aspects shown in one map but omitted from others) they uncovered a deeper truth: one that could be used to break out of habitual behaviour. We were able to see this in action as Jerry explored with five members of one organisation how the "wall of mistrust" shown on their maps was both self-constructed and easily surmountable.
It also stopped raining today. It was wierd to be in desert country with rain pouring down, though apparently Phoenix does have a monsoon season (normally August, according to Linda Rising who lives locally). But now the sun is shining again, and the date palms look less incongruous and the pool more inviting...

AYE pre-conference day

2004-11-07T18:13:00.000-05:00

I hadn't originally planned to attend the Sunday tutorial as it meant I would lose yet another day away from my family, but Alan persuaded me otherwise (pointing me at some very complimentary reviews from previous years). I'm glad he did: it really deepened my existing (albeit mostly theoretical) knowledge of tools such as the Myers-Briggs Type Indicator (MBTI), Satir's interaction model and Satir's change model. At the end of the day we discussed congruent behaviour and coping stances with examples provided by a bizarre (but effective) set of masked visitors for which Esther Derby deserves an acting award of some kind!
After the tutorial there was a pre-conference dinner in which I took the opportunity to sit next to The Great Man (!) Jerry Weinberg. He had some nice words to say about XP and a lot of amusing anecdotes to share: it was a fabulous way to wrap up the day.

On the way to AYE

2004-11-06T04:00:00.000-05:00

I'm lucky enough to be attending the AYE conference this year. I should have been going with Alan Francis but he's just started working in Sydney (Australia). Dave Hoover is taking his place instead - I'm looking forward to meeting him after the email exchanges we've had since he started working at ThoughtWorks. And I'm also looking forward to catching up with Rachel Davies whose enthusiasm at the London eXtreme Tuesday Club* really helped me start out along the professional road that led me here at this place in time.

*Obligatory plug: the XTC is running its fourth London XPDay this year. Register today to hear some of the best agile software professionals explain what they do and why!

MockObjects in the Thames Valley

2004-11-06T03:21:00.000-05:00

Duncan Pierce and I hosted a MockObjects workshop for the Thames Valley Agile SIG on Thursday night. There wasn't a large turnout but on the plus side that gave us more of a chance to talk about the link between using mocks , and CRC cards, and "tell don't ask" design. If you are interested in XP or other agile techniques, and are within travelling distance of Oxford, I'd recommend coming along to swap war stories and exchange ideas. We're planning to play some of Bill Wake's games in our December session which should be fun.

FDD or DDD not BDUF

2004-10-29T13:17:00.000-04:00

David Anderson's post about the roots of FDD started me off on a trip down memory lane: I fondly remember receiving the Coad Letter by email, hearing Peter Coad in person talking to the BCS about "Modelling in Colour", and being inspired by a "Better Software Faster" workshop run by Andy Carmichael. All of which probably makes it apparent that I believe in constructing models as an important part of a software development process.
Modelling has unfortunate "Big Design Up Front" connotations though, despite people like Scott Ambler and Eric Evans demonstrating that it doesn't have to be that way. These kind of models - the small-in-ambition ones that help us to turn stories into code via specific test cases - have remarkably similar characteristics to the programming languages described as "New Jersey style, not MIT/Stanford style" in The Rise of Worse Is Better: the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained.

Dysfunctional teams

2004-10-29T11:56:00.000-04:00

I just came across a reference to the book "The five dysfunctions of a team". Lencioni's five dysfunctions are: absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. In software development teams I think that lack of honest communication is also a common dysfunction - I say what I think you want to hear, or you choose not to hear what I want to say - though honesty itself hardly flourishes without trust and the ability to handle conflict.

Abundance vs. scarcity

2004-10-29T09:12:00.000-04:00

Towards the bottom of a recent post about testers and developers working together, Brian Marick writes about the cultivatation of "a gift economy of the sort described by Marcel Mauss, one where a person's status depends on how much she gives to others." His observation struck a chord with me: a characteristic of the high performance teams I have seen is that they maintain a culture of abundance and optimism, despite facing the same challenges that lead to a culture of scarcity and fear in other teams. (Interestingly, I have probably seen some of the highest performing individuals in these other teams. I'm still undecided whether to believe that the teams performed less well overall "despite the Star Player" or "because of the Star Player".)

As a coach I know that I want to share with others some of what I know and enjoy about software development, and to demonstrate that such things can (and should) be shared.

Me and my persona(s)

2004-10-15T20:49:00.000-04:00

"Agile / TDD / XP is all well and good but how does it fit with..."

A "but" I've heard a couple of times recently is "how does it fit with user-centred design". One way of approaching an answer is to look at customer tests (as JB Rainsberger does here). And another way that I find works well is to approach it via user stories: define stories in the format*

"As <a persona> I would like <feature> so that <goal is achieved> in order to <produce business value>"

and the scene is set for the fruitful discussion of personas, features, and goals.

*Not a format I came up with: it was passed on to me by TimMackinnon, Rachel Davies and Ivan Moore in their Connextra days...

Dads

2004-10-15T20:24:00.000-04:00

Despite the strapline on my blog I haven't written much about being a dad. Maybe it's because being a dad is hard. (And it seems harder the more you care about your kids, your partner, your own parents-that-are-now-grandparents, and the kind of world you live in.) Or maybe it's because being a software-developing-dad is just too far out of the mainstream?
Several of my software development colleagues and ex-colleagues have started families of their own recently, and I wonder what kind of advice I might offer them, with the benefit of hindsight, now that both of my own kids are at school? What would I have wanted to know when I was in their situation?
I'll think on that and post a response later...

Engineering an ineffective team

2004-10-15T20:03:00.000-04:00

It's unfortunately far to easy to engineer an ineffective software development team. How about these ways to start with...?

Create an awful working environment... and prevent the team from changing it. (Don't know how to create an awful workspace? Use this handy list. You could make it: too hot, too cramped, too isolated from the team's customers, too loud, too dark, too busy, too rundown - preferably with furniture that is uneven, unsteady or falling apart, too obstructed by partitions and cubicles, lacking whiteboards, lacking shared space, or lacking necessary software / hardware / connectivity...)
Give the team conflicting goals... and be adamant that you require all of them to be met
Set meaningless deadlines... like slicing 30% off all the team's estimates "to set stretch targets"... and hold the team to those deadlines, no matter what happens in the meantime
Or set a meaningful deadline... but make the team agree to complete more work before the deadline than they believe is possible
Get upset if you ever see developers not "hard at work" (i.e. hunched over their keyboards)... especially if they're "wasting time" by talking to one another
Track the effort spent by individual team members on each development task... and reward those who spend the least time on "their" tasks... regardless of the quality of the work they produce
Ostracise members of the team who don't want to spend their weekends working to fix bugs... that they knew 6 weeks ago would be the result of the corners cut "because we don't have time to do it right this time"
Insist that the team's software must conform with common architectural standards and guidelines... without allowing the team to discuss their ideas with any of the people who drew up the standards and guidelines
Stick rigidly to the original plan of action that was drawn up when the project was conceived... no matter how much the business or technical environment alters. (You may of course revise the plan at any stage if the political environment alters.)
Never - EVER - tell the team that they are doing a good job... instead keep them motivated by fear: the fear that they will be late, that they are useless because they are going to be late, and that they will lose their jobs because they are going to be late
Persuade the team that they have no need to talk to anyone who will ever actually use the software they are creating (or in fact to talk to anyone who understands the business drivers behind the software project)... instead give them a pile of documentation to read (preferably written by another team that has since been disbanded)
Perform all testing after the "development complete" milestone date... even if that milestone slips and the duration of "allowed testing time" is squeezed... Certainly don't provide any functional test data until after "development complete"
Don't allow testers and developers to talk to each other to reach a common understanding of the customer's needs... and reward testers for the number of "defects" they raise, even if those defects are in fact just misunderstandings
Leave all users out of any workshops, walk-throughs, or testing before the "user acceptance phase"... and then allow all their concerns to be raised as "critical defects" without effective prioritisation
Ignore any arguments in favour of "non-standard" hardware or software... or "non-standard" programming languages... even if they might save time or money
Make sure that the "framework" required by the application is completed before development of the application starts... and have the framework be developed or architected by people outside the application team

This is a deliberately contrarian response to Laurent Bossavit's original post on engineering effective teams. But it was fun to write it :-)

And / Or

2004-10-15T06:10:00.000-04:00

Esther Derby's recent post about "but / and" reminds me of an "and / or" reframing I find useful. When I give myself a deadline to achieve several things and have high expectations of how much is possible, I often find that I slip into a frame of mind where I'm thinking like this:
success = completing this AND completing that AND completing the other thing AND...
failure = not completing this OR not completing that OR not completing the other thing OR...
When I'm thinking like this there's only one possible way to feel successful, and many ways to feel unsuccessful - even if there are factors outside my control that make completing a task impossible. When I catch myself doing this try to I reframe the situation* like this:
success = completing this OR completing that OR completing the other thing OR...
failure = not completing this AND not completing that AND not completing the other thing AND...
In this healthier frame of mind I can get on with tackling a mountain of work without the fear of failure hanging over me. Unsurprisingly I also work better when I'm not weighing myself down with excessive expectations.

* Obviously I have less control over other people's expectations of me or the deadlines that they set, but that doesn't prevent me from reframing my own point of view. If I don't meet someone else's over-ambitious target then reframing my point of view allows me to take pride in what I did achieve, and to also to consider (free of shame or guilt) whether the target I was aiming for was realistic or how I might achieve more in a future similar situation.

How much is too much?

2004-10-08T13:53:00.000-04:00

The feed to Dave Astels' blog recently became my 100th BlogLines subscription. (I guess I should have added it a lot earlier, especially after he was nice enough to include XMLUnit in his book on TDD, but the last time I stumbled across the blog it had a ghost-town feel to it and my roving mouse finger moved on elsewhere.)
A hundred blog feeds feels like a lot - but is it really? Is there such a thing as too much reading? Will I get so distracted by other people's opinions that I start to ignore my own gut feel or experience? Or worse still, will I lose the capacity for any creative thinking of my own?! Watch this space, I guess...

The downside of original thinking

2004-09-21T13:11:00.000-04:00

Alan Kay's reflections on the history of Smalltalk (referred to in an earlier post about design) has this to say about the process of innovation:
New ideas go through stages of acceptance, both from within and without. From within, the sequence moves from "barely seeing" a pattern several times, then noting it but not perceiving its "cosmic" significance, then using it operationally in several areas, then comes a "grand rotation" in which the pattern becomes the center of a new way of thinking, and finally, it turns into the same kind of inflexible religion that it originally broke away from.
Perhaps seing this cycle is the reason why some people accuse XP evangelists of peddling an inflexible religion or purist cult? (Deeply ironic given that most XP coaches offer the advice to start with what has worked for other people - e.g. as described in the Pink or Purple XP books - and then to customise the process to make it work for you.)
Reflection: have you seen other people turn innovative ideas into an inflexible religion? have you done it yourself? what kind of feedback does it take to break out of rigid patterns of thought or behaviour?

Look to your own behaviour

2004-09-18T17:55:00.000-04:00

Q: What’s the most important piece of management-related advice anyone has ever given you?
GW: If you blame your employees, you're a bad manager. You hired them, accepted them, supervised them, and directed their training. You’re responsible. If you don't like what's happening, look to your own behavior. But, if there's credit to be given, it's theirs.

The selfish path to agility

2004-09-17T05:55:00.000-04:00

I read yet another article about the need to align IT skills and business needs: The IT workers of tomorrow will be those with the broader skills, the appreciation of business and processes, of project and programme management. Like it or not, many technical skills are being commoditised - what is the difference between an IT expert trained in, say, Java, who is based in India, and one based in the UK? The skills are identical. The cost differential is well-known. IT is no longer a silo, safe in the knowledge that nobody else understands what it does and therefore is irreplaceable.
Yup, I agree with that.
Then the article goes on and concludes: The IT professionals of tomorrow will be those that learn the business skills that ensure they maintain their influence.
Erm, no. I think that the IT organisations (and IT professionals) of tomorrow will be those that make the transition to agile. The inclusivity, collaboration and communication required of agile teams not only reduces the "business - IT gap": it also increases productivity (as Mary Poppendieck describes here). In the short to medium term I'd say that the potential to affect the bottom line (e.g. through better targeting of business value) is going to be the most important factor in the widespread takeup of agile. It's certainly thought-provoking to imagine that an appeal to individuals' self-interest ("go agile or bust"?!) could further the spread of co-operative team working...

Agile is not a product

2004-09-15T12:44:00.000-04:00

I love this post from Ken Schwaber on the scrumdevelopment Yahoo group (thanks for passsing it on, Laura!): I believe that Agile is part of a social revolution to help people learn together to collaboratively figure out how to work and live in an increasingly complex world. Agile is an attitude, not a product. Agile is spirituality, not a religion. We don't have to sell it as a product. We don't have to evangelize it. We simply (and with difficulty) have to live it. People will observe us and envy our joy at work, and quake in fear and be defeated by our productivity. For the old way of doing things doesn't cut it anymore. The Agile way is the appropriate response to our complex times.
Postscript: perhaps Agile is a passion? Ron Jeffries wrote: I've had people love me and had people hate me, and while I prefer the love by a wide margin, I kind of prefer either to indifference. Because I'm not about making indifference, I'm about making a difference. That's what I think this movement is about: making a difference. That's what I want it to be about: making a difference. Count me in!

More on play: the players

2004-09-10T11:51:00.000-04:00

While I was googling for background information on Pat Kane's book "The Play Ethic" I came across this insight into the nature of great team players:
How much is there to learn from this disquisition on the relationship between individual play and team play:
You have this game with 22 players, all of them individuals, and yet they form two teams. Everything in this field of sport is contradictory. The 11 of you must operate as a hermetic group, while each player is constantly being judged on his individual performance. Eleven ways of thinking, 11 opinions, 11 personalities - how can they ever agree? And yet on the field a common goal must be set. Another complication is added: the problems that arise when things are not going well, appear in reverse when all is going smoothly. If there is a hitch, the guys, by being organised and not solely relying on their own insight, will give all it takes to get things back on track. If the game is progressing optimally, then these players will all want to stand out again anyway.
Cruyff's own solution? "I always went against the grain of all the accepted opinions. I dared to say to myself: 'Today is not important.' So I do not really have to go around that guy now and shoot the ball in the goal myself. If the organisation is sound, we will succeed - maybe not today, but tomorrow." (sourced from Brain Waves).

TVASIG, an XP Game, and the Play Ethic

2004-09-10T02:47:00.000-04:00

I drove to Oxford last night to go to a meeting of the Thames Valley Agile SIG and take part in an XP Game. Quite a few people came along, though there seemed to be more developers present and less managers than I remember from the last couple of TVASIG meetings. (Which is a shame: as Olivier Lafontan said, the XP Game shows how the act of measuring value and calibrating velocity starts by addressing real business concerns and then leads naturally on to the other developer-centric XP practices.) All in all, the evening was both fun and eductional, which is appropriate given that we were "playing a game".
By coincidence, as I was driving and listening to the radio I heard a discussion about a book called "The Play Ethic". I was really struck by the subversively life affirming nature of some of the ideas, for example: The play ethic is about having the confidence to be spontaneous, creative and empathetic across every area of you life - in relationships, in the community, in your cultural life, as well as paid employment. It's about placing yourself, your passions and enthusiasms at the centre of your world. By clearing space for activities that are pleasurable, voluntary and imaginative - that is, for play - you'll have better memory, sharper reasoning and more optimism about the future. As Brian Sutton-Smith, the dean of Play Studies at the University of Pennsylvania, says, 'The opposite of play isn't work. It's depression. To play is to act out and be wilful, exultant and committed, as if one is assured of one's prospects.' So to call yourself a 'player', rather than a 'worker', is to immediately widen your conception of who you are and what you might be capable of doing. It is to dedicate yourself to realising your full human potential; to be active, not passive.
The timing of that message is apt: I recently gave notice that I am leaving my current position, in part because I want to spend more time as a "player" and less as a "worker". (Don't get the wrong idea: Thoughtworks is not a bad organisation to work for, and I have never come across such an amazing concentration of high quality people as I have whilst working there). But after two years I have become uncomfortable in a rapidly-growing consultancy focussed on the delivery of difficult software projects for large organisations. It's somehow both a strength and a weakness of my personality type that I want something with more of an emotional connection to my life and my values: INFJs value their integrity a great deal. They are generally "doers" as well as great dreamers. They have high expectations of themselves and need to live their lives in accordance with what they feel is right. They do this through total trust of their intuition. They believe in constant growth and don't often take time to revel in their accomplishments. INFJs are proud of their authenticity, respectful of their benevolence, confident of their empathy. They also are constantly in a state of self-renewal.
Now certainly feels like the right time for self-renewal...

"You can't be a little bit agile"

2004-08-19T06:24:00.000-04:00

Thanks to Bill Caputo for pointing me at this article from CIO Magazine. Two paragraphs really stood out for me:

To become agile, everyone in IT has to understand the business inside and out. IT can't stay on top of business needs, or react quickly to new market opportunities, if it doesn't know or understand the business drivers. And just as the IT department must foster flexibility and responsiveness across a number of disciplines inside IT, companies have to promote that same flexibility and responsiveness across all their business units. Giving a stodgy business an agile IT department is like giving a fish a bicycle. There's nothing like bureaucracy to put the kibosh on agility. Agility has to be the mantra of the the company at large, and as BCBS of RI's Zink says, it has to be supported by the top executives.
You can't be a little bit agile. You can't be agile in one area and not in another. You need agility in staffing, architecture, budgeting, governance, vendor relations and programming. And if that sounds like a lot, well, it is. But it's worth it.

The attempts that I have seen to weld agile software development to a bureaucratic business organisation have not been totally successful. The executives in those organisations would probably deny it but the lack of an agile organisational culture was definitely driven by the example that they set. (Off-topic: is "do-as-I-say-not-do-as-I-do" the opposite of leadership?)
To me the biggest challenge of being a software coach is uncovering and addressing the organisational barriers to an agile style of software development. Some of these barriers are addressable within a single team or IT department, but many of them are not. How many clients want to hear that "being Agile" is a destination that may be reachable after cultural change throughout the organisation, not a silver bullet that they can shoot their IT department with?

Time to take it slow

2004-08-18T03:15:00.000-04:00

The Slow Food movement promotes an alternative view of the preparation and consumption of food. In their eyes fast food is the inevitable outcome of an approach to life in which people can be treated as machines and ceaseless haste has become a virtue: "We are enslaved by speed and have all succumbed to the same insidious virus: Fast Life, which disrupts our habits, pervades the privacy of our homes and forces us to eat Fast Foods."

The movement's emblem is a snail, appropriately enough: the Snail is "of slow motion, to educate us that being fast makes man inconsiderate and foolish"; since it carries its house, "wherever the Snail is, that is its home". I think that the message here is applicable beyond just food: consider for example the differences between "fast software" and "slow software"*.

Fast software is churned out for minimum cost by low-skilled staff that have few opportunities for growth or advancement. (The true cost of the production of the software is hidden from the consumer at the time of purchase.) The need for conformity to the fast software production process subsumes the individual needs or talents of the staff, and requires that different products have similar "ingredients" (tools, languages, architectures) and hence similar "taste" (user experience, fit to business need). The quality of fast software is uniformly low but the brand power of the producers maintains aggregate consumption levels. Consuming fast software brings little sense of satisfaction but it requires little effort and you can rest assured your competitors are doing the same.

Slow software is crafted by skilled teams that come together to meet the particular needs of a single purchaser. Each slow software project evolves in its own way, and each member of a slow software team is expected to bring their unique skills to bear on the challenges faced by the team. Working on a slow software project provides opportunities for team members to both pass on and gain expertise. Slow software teams make careful tool and technology choices to suit their operating environment, and pay constant attention to the needs of their users and customers. Because slow software teams take pride in their work, slow software is of high internal and external quality, and slow software producers gain new business through recommendations by satisfied customers rather than through branding or advertising. Consumers of slow software engage with the producers during the production process, and although this requires time and resources it is a rewarding experience that provides a significant business advantage.

This contrast characterises what I see as some of the essential differences between the mass-market big-consultancy approach to business systems development (fast software) and a smaller scale alternative that emphasises craftmanship and diversity to the benefit of all parties (slow software). And perhaps the pursuit of slow software is one way of satisfying the principles behind the Agile Manifesto?

* In 1607 Francesco Angelita wrote a book about snails in which he said that humans had much to learn from them: Slowness was an essential virtue, as was adaptability and the ability to settle anywhere, in any situation. By slowness, he meant both prudence and solemnity, the wit of the philosopher and the moderation of the authoritative governor. We could extend this interpretation to say that the snail takes its time as it trails along, impervious to haste and readily at home everywhere.

Postscript: Bob Martin covered much the same ground earlier this year: You don't have time not to do it right! Where did we get the idea that our companies wanted us to write crap? Aren't they paying a lot of money for this software? Aren't they going to depend upon this software for profits? Isn't this software worth a lot? If so, then why would our company want to pay for crap that slows us down? Wouldn't they rather have good clean code that keeps us running fast?... Remember, two years from now all people will see is the mess, they won't see how fast you got it done. Nobody remembers the speed, they only remember the mess. So do it right... Take my advice: go well, not fast. Care about your code. Take the time to do things right. In software, slow and steady wins the race; and speed kills.

The iteration-is-not-a-unit-of-work antipattern

2004-08-11T13:37:00.000-04:00

This is an antipattern that I've seen a few times in teams that are making the transition to XP or agile development. It manifests itself when organisations that are used to thinking about fixed time and scope projects draw up a release plan, typically the plan for the first release. The stories are discussed and prioritised and allocated to iterations as usual, but from that moment on the plan is treated as if it were fixed, and as if the delivery of specific stories at the end of specific iterations was guaranteed.
But of course it does nothing of the sort. The iterations in a release plan are not units of work ("these stories") but units of time ("this many days"). Trying to make an iteration into a unit of work requires that either its length varies to reflect actual effort required, or that the team is put under constant pressure to squeeze varying amounts of effort into some arbitrary time span. In the first case it's hard to track work completion properly and commitment to a release date becomes impossible; in the second case quality and morale slips and the team (including the customer) loses the ability to steer the project in a way that accomodates change.
Reflection: have you seen this antipattern? What was the outcome? What lies behind the desire for a release plan to be fixed or guaranteed? Are the other ways of dealing with these forces that would not cause an iteration to be treated as a unit of work?

New RSS feed

2004-08-05T03:41:00.000-04:00

My RSS feed is now provided by FeedBurner - it is much higher quality than BlogStreet ever managed! (The Atom feed is available as always.) Thanks to Ade for pointing me in the right direction :-)

If design is dead then when was it alive?

2004-08-02T20:39:00.000-04:00

[This little post has been a draft for too long. Time to let it loose I think...]

Among Mike Hill's FAQs and FUNQS from XP2004 is the following gem about the skills of developers he has met:
Based on my experience:
– 30% [of developers] need basic language training.
– 50% need OO training.

The problem is, what kind of OO training would be effective? Exposure to good designers and good designs would surely help, as would working in an environment that exposes the monetary cost / benefit tradeoff of a good design. (As Martin Fowler puts it: If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify. In my opinion I think that "to modify" means "for more than one person to work on for more than one day".) It is frustrating to keep on hearing of the confusion between the simplest design and the problems of simplistic design. Surely simple design has aesthetic qualities such as self-similarity, elegance, or coherence; whereas simplistic design is repetitive, inconsistent, and plain ugly?

This is what Alan Kay has to say about OO design and the history of Smalltalk: Bob Barton... had said in one of his talks a few days earlier: "The basic principle of recursive design is to make the parts have the same power as the whole." For the first time I thought of the whole as the entire computer and wondered why anyone would want to divide it up into weaker things called data structures and procedures.
Later, I sat in the room pondering the board from my talk. Finally, I counted the number of nonobvious ideas in this little program. They came to 17. And some of them were like the concept of the arch in building design: very hard to discover, if you don't already know them. The connection to literacy was painfully clear. It isn't enough to just learn to read and write. There is also a literature that renders ideas... at some point the organization of ideas starts to dominate mere language abilities. And it helps to have some powerful ideas under one's belt to better acquire more powerful ideas. So, we decided we should do design.
When, in what order and depth, and how should the powerful ideas be taught? Should we even try to teach programming? I have met hundreds of programmers in the last 30 years and can see no discernable influence of programming on their general ability to think well or to take an enlightened stance... A twentieth century problem is that technology has become "too easy". When it was hard to do anything whether good or bad, enough time was taken so that the result was usually good. Now we can make things almost trivially, especially in software, but most of the designs are trivial as well. Really? I hope not.

FYI: learn lean through Agile Scotland

2004-08-02T09:55:00.000-04:00

The Agile Scotland group have organised for Mary Poppendieck (author of the excellent book Lean Software Development) to give her "Implementing Lean Software Development" course in Edinburgh in October.

Agile Development Conference

2004-07-20T02:51:00.000-04:00

I didn't make it to ADC this year (I wanted to do so but I couldn't get the time and money together... though I will be attending the AYE conference in November which I am really excited about.) Anyway I know several people who did make it there and it sounds as though there was a real diversity of topics discussed and experiences shared. (Andy Pols has blogged his view of the highlights, and he should know...) I believe that conferences like this demonstrate that "agile" has become more than just a marketing term, despite differences of opinion about what the precise definition of the term is.

Red-Green-Refactor = Add-Add-Remove

2004-07-16T05:25:00.000-04:00

Are there just three steps to TDD enlightenment?

Step 1. Add code:
Write a test. Run it. Watch the bar go red.

Step 2. Add more code:
Write just the method or class implementation needed to make the new test pass. Concentrate on making the smallest number of changes and resist the urge to keep the code clean. Run the tests. Watch the bar go green.

Step 3. Remove code:
Improve the code by refactoring. This will almost certainly involve removing code, either by deleting duplication or simplifying complexity. Re-run the tests. Watch the bar go green. Repeat this step as needed or return to step 1.

Reflection: when you refactor do you find yourself removing code? do you like or dislike removing code? does the answer depend on whether "your" code is being removed by others or by yourself? should it?

Urgency, importance and technical debt

2004-07-03T17:07:00.000-04:00

A useful piece of time management advice is to distinguish between tasks that are urgent and tasks that are important - and then to ensure that important-but-not-urgent tasks (which are often overlooked) actually get done. Which seems a lot like the advice for software development teams to avoid technical debt. Repaying or avoiding technical debt is important but is rarely foremost in the minds of customers or managers. And despite the adage that "you'll pay for it [technical debt] today or you'll pay more for it tomorrow" software development organisations are often unwilling to confront the scale - or implications - of the problem.
Reflection: Do you find yourself fighting fires more often than you are creating fire engines? Is refactoring treated as an optional extra task in your estimates? How might you maintain a better level of slack? What can you do if you recognise the symptoms of undertime in yourself or those you work with? What time management lessons would your team learn if time were available for retrospectives between project releases?

Postscript: I recently caught up with Dave Hoover's blog and this entry struck a chord. To bring this back into the realm of software development, the problematic symptom is time pressure. The fundamental solutions that could treat this symptom include delaying the release or shipping without the functionality... One of the easiest and most immediate ways to suppress the symptom of time pressure is to stop writing unit tests.

Organisational patterns finally made it into a book

2004-07-01T09:59:00.000-04:00

I heard Jim Coplien speak about organisational patterns at a BCS OOPS conference back in 1997, and it seems as if he is now publishing his ideas in the book Organizational Patterns of Agile Software Development. (BTW because of the book's long gestation period some of the earlier material is still available on the web. Take a look at the "Architect-Also-Implements" pattern if you do nothing else.) It looks as though the book will be a must-read when it comes out.

Agile Alliance newsletters

2004-06-10T20:04:00.000-04:00

Back issues of the "Agile Times" can now be downloaded from the Agile Alliance homepage. (Shameless self-promotion: Vol 4 of the newsletter includes an article I contributed on Asking Effective Questions.)

Thames Valley Agile SIG

2004-06-02T14:46:00.000-04:00

I was the guest speaker at the Thames Valley Agile SIG last night. There was a good turnout and a lively discussion afterwards in the pub. It was great to talk to first-time agile practioners (mostly using SCRUM) and to the early-adopter-developers who are trying to infect their organisation with the agile virus.

Postscript: the slides I provided have moved to the files area of the TVASIG Yahoo Group. You will need to sign up as a member to see them.

Coaching the Alpha Male

2004-05-17T04:40:00.000-04:00

This article on executive coaching says: Highly intelligent, confident, and successful, alpha males represent about 70% of all senior executives. Natural leaders, they willingly take on levels of responsibility most rational people would find overwhelming. But many of their quintessential strengths can also make alphas difficult to work with. Their self-confidence can appear domineering. Their high expectations can make them excessively critical. Their unemotional style can keep them from inspiring their teams... Coaches get the alpha's attention by inundating him with data from 360-degree feedback presented in ways he will find compelling. Such an assessment is a wake-up call for most alphas, providing undeniable proof that their behavior doesn't work nearly as well as they think it does. That paves the way for a genuine commitment to change. To change, the alpha must admit vulnerability, accept accountability not just for his own work but for others', connect with his underlying emotions, learn to motivate through a balance of criticism and validation, and become aware of unproductive behavior patterns.
Reflection: What sort of working environments would prevent an Alpha Male from admitting any kind of vulnerability? What sort of environments would push software Alpha Males "to the top"? How would you coach an Alpha Male developer or a software team in these sorts of environment?

A problem cannot be solved by the same level of thinking that created it

2004-05-06T09:36:00.000-04:00

One of the thorniest problems in the transition to agile software development is finding the right role for a traditional project manager. Here are some of the prevalent options and attitudes:

Strong management is absolutely critical to the successful adoption and application of agile methodologies.

"Underperformers take an inordinate amount of energy to manage," says Jim Bolton, CEO of Ridge Associates, a communications consulting firm. "You not only have to manage their performance, but, as chronic offenders, they become problems in yourperformance."

Advanced PM strategies: Communication, Amicability, Priorities, Focus time, Skills development, Motivation, Reflection

The best project managers aren’t just organizers – they combine business vision, communication skills, soft management skills and technical savvy with the ability to plan, coordinate, and execute. In essence, they are not just managers – they are leaders.

Let us understand that often our process for dealing with a problem, setting a goal or resolving an issue is flawed.
That we are repeating old habits, trying to accomplish new tasks with outmoded thinking.
That we may have the knowledge or the potential to solve the issue but our process boxes us in.

Reflection: Which of these attitudes corresponds with the behaviour seen in your organisation? Is the behaviour of your project manager influenced by the expectations of the organisation? What role do you think your project manager would play in an agile team?

Total Eclipse of the IDE

2004-05-03T17:15:00.000-04:00

I try to keep an open mind about the tools I use to develop software (it helps that one of my personal value statements is "diversity over uniformity".) In my experience each IDE, compiler, framework, language and so on has both strong points and weaknesses. But I do find it helps to deliberately try a new or different tool from time to time and reflect on what I learn from doing so. So in that vein I offer this little snippet from my own experience - not wanting to participate in any "religious wars" between IDE devotees :-o
One of the nicest things I have found about working with Eclipse is that it allows you to forget about compilation problems. You can happily write and run JUnit tests when your code won't compile, even tests that reference broken classes or methods. This feature really resonates with me because I can proceed through multiple test-code-refactor cycles with just baby steps, where other IDEs would make me go off on a long detour to fix all the compile errors before I could even run the test I wanted to focus on. In situations that require several refactorings to introduce a new feature, keeping the ability to concentrate on one thing at a time is just what I need.
Reflection: Which IDEs have you used? What do you like or dislike about each one? What are the particular circumstances in which one would be preferable to another?

Prioritise scope - don't cut it

2004-04-29T02:42:00.000-04:00

In an agile project a lot of effort is spent in managing the scope of a release. But managing scope is not the same as cutting it. Managing scope includes adding and substituting work as well as removing it. Whereas cutting scope is an irreversible activity and hence a form of premature optimisation. (As experienced programmers know well, premature optimisation is the root of much evil.) Scope cutting fails to differentiate between "we don't think that this is important enough to do" and "we don't think that this is important enough to do now", and it promotes a binary view of the project (activities are "in scope" or "not in scope") that doesn't fit with the style of nimble decision making - and remaking - that agile processes allow.
Reflection: Do you keep track of the stories or features that are managed out of a release? Why? Would past scope management affect the planning for future iterations or releases?

Clearing out my backlog

2004-04-14T04:19:00.000-04:00

I recently realised that I am trying to carry too much of a personal backlog: my head won't fit any more draft blog posts, code snippets, open source thoughts, or potential problem-solutions. So in accordance with the Lean Principles I decided to cut out some unneccessary work in progress. The first step is to get some of my "great unwritten blog posts" out into the open, and I may (or may not) revisit these ideas in the future...

Agile is not careless: one of the criticisms levelled at agile software development is that there isn't enough emphasis on planning. But agile teams are not careless: we do plan and replan frequently, in a low ceremony manner that values "the planning activity" more than "having a plan (and sticking to it)". A software team which does no documentation is not doing XP, and a team which does no replanning is not being agile.

Don't just throw people at the problem: throwing a team of good people at a problem and hoping that they will succeed in spite of any obstacles is far too wasteful. It's much better to proactively identify and overcome obstacles with some thoughtful agile project management instead.

Does testing need more domain-level scripting languages?: if FIT enables application test-scripting in a generic fashion, then what could be done with more specific domain-level scripting languages - especially if they incorporated some of these ideas on Situated Software?

Comparing agile methods to the CMM: rather than comparing agility and discipline (repeat after me, XP without discipline is a recipe for failure) I see it as an apples-and-oranges comparison between repeatable outcomes and repeatable processes...

The environment matters: According to this BBC News report cluttered desks make workers ill. And I thought that there were already enough reasons to pay attention to the work environment, given the morale and productivity-sapping effects of cube farms, open plan prairies, poor (or non-existent) air conditioning, cramped seating, and the like...

Think your design is good? The bar is higher now

2004-04-08T06:09:00.000-04:00

This post to a forum on Artima.com illustrates how the application of Test-Driven Development techniques leads to better code. Michael Feathers wrote: Pick a class, any class, and try to instantiate it in a test harness. I used to think that my earlier designs were good until I started to apply that test. We can talk about coupling and encapsulation and all those nice pretty things, but put your money where your mouth is. Can you make this class work outside the application?
Reflection: if you can't make this class work outside the application then what are the reasons? How much work would it take to disentangle the class from this specific application?

A time to act and a time to think

2004-04-07T16:41:00.000-04:00

Uncle Petros and Goldbach's Conjecture contains a passage that relates how for a mathematician to spend time away from the problem at hand is essential. Mentally to digest the work accomplished and process its results at an unconscious level requires leisure as well as exertion. In other words making progress requires more than the "application of perspiration" to the problem at hand. The spark of insight may come from "inside events", "outside events", or "other people" (for example a dream, the observation of an apple falling from a tree, or a chance conversation).
Professional mathematicians work in a way that reflects the nature of thought-work but unfortunately software teams often don't. To be most productive a developer requires time away from a keyboard and monitor, quietly reflecting or talking with colleagues. It can be hard for a client / sales / management representative to see the value being created in this time, but allowing developers the thinking time they need leads to higher quality work.
Reflection: What are the barriers to thought-time in your organisation? What forces or events caused those barriers to be erected? Can these forces be overcome in other ways?
(Thanks to Dave Farley for the conversation that stimulated this posting.)

Mistaken about mistakes

2004-04-03T08:09:00.000-05:00

Broken build rituals are one way to instil good habits in a team that uses Continuous Integration. But the fact of the matter is that people make mistakes: it's part of what makes us human, as many authors and playwrights have explored. (You could argue that making mistakes is necessary to our development: my kids certainly learnt to walk by repeatedly falling over and then trying not to do so next time.*)
Seeking out the reasons why and how we make mistakes after we make them is hard to do. It requires humility and courage, attitudes that are hard to adopt if we are smarting from self-realisation or suffering from embarassment or guilt. But while we may feel that our mistakes are ours alone, it often turns out that the systems and processes within which we work have an enormous influence.
This is the ground occupied by Systems Thinking. Deming and others have made systemic examinations of the culture(s) of work, and describe ways by which our effectiveness can be improved by considering "the bigger picture". This article in particular really strikes a chord: Transformation of an organization, from one that resembles the "win-lose" environment of the "prevailing style of management" to one that is Deming-based ("win-win"), has been shown repeatedly to require systemic change. Vital to this transformation is "better thinking" by individuals in these organizations about systems, variation, knowledge, and psychology.

*Follow up: I just read this conversation with Luke Hohmann in which he says Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked.

What agile means to me: what I do and who I am

2004-04-02T04:30:00.000-05:00

My previous post was a bit of April Fool-ishness. But it made me consider a serious question: why am I such an advocate of Agile software development, and what would it take to make me change my opinion?
I think that there is both a simple and a complex answer.
The simple answer is that, in my experience, Agile software development works. I have been involved in many different projects, each of which had their own style, and those that were agile produced the best results, i.e. the most frequent delivery of working software with real business value. However my experience is just that, and my (re)collection of past events is not the same as anyone else's. As Mr Ed acerbically points out just because XP has worked for me this doesn't mean that XP will work for you. (His argument that because XP has not worked for him it can't work for anyone else is quite ridiculous though.)
The complex answer is that the values espoused in the Agile Manifesto (and by XP in particular) resonate with me at an emotional level: XP ain't out there, it's in here. My personal values certainly include feedback, communication, courage and simplicity and I enjoy working with others who feel the same. I find it both unpleasant and difficult to leave part of my self at the door as I arrive at work, something I know I have to do when working in a non-agile team. I work best in an environment where people treat others as they themselves would like to be treated, away from the arrogance of "architects" who feel that coding is for "monkeys", and away from the unthinking bullying style of management that is the opposite of leadership. What I do at work is more than manipulating symbols on a computer screen. Being who I am is about collaborating with others to solve practical problems (and expressing those solutions in a well-factored, readable, and test-exercised software system). It's quite a standard to live up to, but that is what being part of an agile project means to me.

Ok I admit it, Agile methods don't work

2004-04-01T14:49:00.000-05:00

How could I (and many others) have been so mistaken? With hindsight it's obvious that a team could never collaborate to create working software without a plan to to tell them what to do and when to do it.Or without a complete set of Requirements Specification documentation, contractually approved by the customer in advance of any actual development. And how did I possibly think anything could be released without a long test-and-fix cycle first? It makes me shiver to think how dangerously irresponsible I was. But that's all behind me now: from here on I will only work in a CMM Level 5-certified environment.

Not ;-)

The stars shone brightly

2004-03-30T15:26:00.000-05:00

I went to my first Tai Chi class tonight, something I've thought about doing since I was at university and saw a group of Chinese students practising. The smooth flowing rhythm of the movements was both relaxing and invigorating, quite an antidote to the physically sterile nature of much of the work I have been doing recently. When the class was over I took a moment outside to gaze up at the beautiful stars overhead, and I could smell the spring hyacinths nearby, and I felt at peace.

Q: What is a coach?

2004-03-29T13:53:00.000-05:00

This is a question that I thought I had a good answer to. Now I'm not so sure. (It doesn't help that much of my original answer boils down to "coaching is the name I give to the thing(s) that I do".) I first felt unsettled as I read what Bill Caputo had written in an email: "Coaching is -- XP or otherwise -- about helping the entire team, define, understand, and improve the practices and processes of that team. As such it is a leadership position -- and also on the ground. I have said more than once, that the best coaches coach by achieving excellence in the practices they are teaching, and living those practices while working on the team -- including and especially the practice of pairing, which is the most effective way they can transfer their knowledge. More evidence that leadership itself is an activity and not synonymous with one's job description".
Could it be that what I call coaching is what other people call leadership? I'm not sure: leadership and coaching are definitely related, but while an effective leader can certainly be inspiritational, the "coach-as-inspirational-example" model seems to be missing something important. But I couldn't pin down what it was at the time.
Anyway a month or so after that I met up with some of my colleagues to discuss whether coaching really is 'just' an activity, and that led to more of a debate about exactly what it is a coach does, or can do (distilled here by Alan Francis). After the dust settled it seemed to me that some people were only interested in discussing coaching in terms of an activity that is done to other people. (The "coach-as-teacher" model.)
Whereas I see coaching very much as an activity that is done with other people, in order to bring about transformations in modes of thought and behaviour. This has become clearer to me as I have been reading up about a guest speaker who is coming to ThoughtWorks to talk about her (executive) coaching work.
This page for instance says: "the need for coaching comes from the absence of true conversation in the workplace" and "genuine human presence is the most subversive and creative thing. As a coach, be present in a way that speaks to the secret subtext of [the client's] potential". This definitely sounds more like the level on which I want to engage...
I'm sure that I'll be posting more on this topic in the future.

Double-entry book-keeping for software systems

2004-03-28T15:30:00.000-05:00

As "enterprise" software grows in scope and scale it becomes harder to keep track of all the transactions that are created. At a certain level of complexity - say high volume work flows containing parallel or time-delayed steps - I think that it makes sense to introduce a double-entry book-keeping approach. Doing so makes it easy to aggregate completed transactions (and the effects of those transactions) and to identify and isolate incomplete transactions - just as accountants do with financial transactions. And it is certainly easier to reconcile between (or across) multiple collaborating systems if you can treat the transactions flowing between them as credit and debit entries that offset each other in a virtual ledger. (This post was prompted by the interplay between comments made by my colleagues about the desirability of queue-based / event-driven architectures, and the problems I have encountered trying to reconcile messages sent between intertwined sales and stock systems.)

In what way is software development an academic subject?

2004-03-20T04:35:00.000-05:00

A UK university is offering students the chance to study for an MSc in agile software. Now I know that this question is almost as old as software development itself, but it what way is software development an academic subject? While I concede that classroom teaching has its place I think that a hands-on approach provides a better framework for CompSci students to appreciate how agile methods address the real-world pitfalls of application development. (BTW Richard Gabriel's proposal for a Master of Fine Arts in software development has a lot to recommend it too.)
I feel quite strongly that proficiency in software development requires a significant amount of experiential learning. Each combination of team, technology and client that we encounter provides an opportunity for us to grow professionally and personally. (And this is a strong argument in favour of the Apprentice-Journeyman-Master model of Software Craftsmanship.) But how many job ads do you see where "significant diverse experience" is seen as an advantage, or even a pre-requisite?
In the continual rush towards 'the next big thing' - a rush that favours the optimism and energy of youth over the caution and steady pace of experience - the software industry seems to embody George Santayana's prediction that, "Those who cannot remember the past are condemned to repeat it." (Apart perhaps from in the *nix / hacker culture, where there is a sense of history, and older heroes can still be role models.)
Postscript: This article by Pete McBreen passionately makes the case that software development is not something that can be easily taught or learnt. In the end, it comes down to the fact that you learn to be a software developer by actually doing software development. Toy problems don't count. What you have to do is work on a project you care about—one that you become passionately interested and involved in. Once that happens, you'll discover that you can learn whatever you need to learn, and that learning a new programming language, while a time-consuming pain, is really quite easy.