Negativity is more infectious than positivity

One happy person can sometimes make someone else on the project team a little more upbeat. But one unhappy person can bring down the mood of everyone else, by being cynical, disruptive, and selfish. The challenge is how to help an unhappy person understand that the person making them most unhappy is themself. Sometimes it's easier to choose to be unhappy - by acting powerless - instead of having the courage to find and exercise whatever power you do have.
After all, once you know that you're unhappy - and why - you can channel your frustration and anger into making change happen.

A question for IT Directors

According to some pseudo-spam I just received a "recent Borland survey amongst IT Directors suggests that almost 70% of firms with a formal software development process did not believe that it effectively allowed them to deliver software on time and within budget."
So why have a formal process (or at least the formal process that they are using)? What does the process allow IT Directors to do if it does not allow effective delivery of working software?

Double or Quits?

How long do you keep trying something that doesn't seem to work? How many times can you put up with hearing that "it will be ready tomorrow, hopefully"? When do you 'throw away' what you've done when there's nothing to show for the time you've spent already?
It's a tough call. If you could see the future, then you'd know what to do. Maybe with the benefit of hindsight others will berate you for having taken what was 'obviously' the wrong decision.
Welcome to the gambler's dilemma.
Before you protest that software projects have nothing to do with gambling then consider the obvious similarities. In both cases there is overwhelming pressure not to walk away from your losses. And in both cases there is a small - but diminishing - chance to pay off all your losses by continuing to bet on the same outcome (the spin of a roulette wheel or the activities of a development team). This is why large, late and over budget projects are given more money or time after failing to deliver. If you were the business person who had commissioned a large system wouldn't you be trying to save face by paying 'a little bit more' to get some of it, rather than admitting that your baby was dead in the water?
But there is another way. With an XP project you don't have to play double or quits like that. You know that what you get every couple of weeks is working software with business value. Any time you want to cancel the project you're still left with a positive return for your investment. That sounds more appealing, doesn't it...?

You write code? Well I write tests...

I saw a ThinkGeek t-shirt with the logo "I wrote code so you don't have to". Now I'll know that Test Driven Development has arrived when I can buy a t-shirt with the logo "I wrote tests so you get working software"....

Conflict and creativity

Some people don't like conflict. There are project managers who won't tolerate any hint of dissent, and there are developers who won't speak up to question a decision. But what if conflict were healthy? What if you could harness the energy produced by conflict and use it to improve your project?
Well, you can: conflict and creativity go hand in hand. Composers for example understand that conflict forms an intrinsic part of their work. Their music progresses from harmony to discord and back again, and the tension created by dissonance pushes the piece forward towards its conclusion.
So, a drifting project could be a project starved of creative conflict. If no-one on the team is proposing ways that the project can be done better, faster or cheaper, then ask yourself: is it because the project is perfect, or is it because the project environment does not tolerate conflict?
A coach understands that a project may improve when the team are challenged to confront some inappropriate assumptions or beliefs. This deliberately introduces a small amount of conflict where before there was none. A common approach is to ask open ended questions such as "Why?", "How do you know?" and "What would that give you?" and it can produce rich results when used at appropriate moments.
So is there enough conflict on your project? How do you know?

Embracing change == confronting reality

XP encourages us to "embrace change". But what is change in the context of a software project? My colleague Darren reckons that the biggest change comes when a project ends: but while that is a significant change, I think that there's a more important source of change. Reality.
Reality bites us all the time, because so much of software development is about constructing abstractions in mental models. We have models of code and design, models of the business domain, models of the how user will use the system, and many more. But when our software is actually put to use then the flaws in those models become apparent, and we have to change our software to accommodate reality. For teams that deliver their software early and often, this means that the most regular cause of change is going to be reality.
In XP this kind of change is just another kind of feedback and it is welcomed accordingly. More generally, the agile manifesto encourages agile software teams to confront reality through the values of working software and customer collaboration.
But un-agile project teams only need to confront reality in the implementation and maintenance phases. Which is perhaps why the maintenance of those projects costs so much: the software was not written to accomodate reality. As my colleague Joe points out, if you wanted to write maintainable software then the things you would do are very close to what the best XP teams are already doing.
So, are you keeping it real...?

Where's the beef? Er I mean the RSS...

A blog without an RSS feed is like a car without tyres (tires to y'all from the US). You imagine it went somewhere you just don't know where it's been. Which I guess is why the folk at Blogger only make RSS feeds available to paying customers, sigh. Anyhow, thanks to the wondrous activity that is googling I stumbled across an RSS feed generator at BlogStreet.com. It's not quite perfect but for all the folks in the world who might like to syndicate these brain dumps then I reckon that it ain't a bad start...

The role of a software coach

A software coach enhances the effectiveness of a software development team by bringing out the team's strengths and mitigating its weaknesses. Just as sports coaches do, software coaches examine the contributions made by individuals and the interplay between team members. But the software coach also often takes the role of facilitatator: moderating in awkward discussions, assisting with brainstorming, or helping the team to reach collective decisions. The coach usually teaches the team new skills as well - a coach will certainly spread the existing good practices that they uncover - and when a coach is used to introduce a new way of working they become the agent of change that makes the transition to the new process possible.
The difference between a software coach and the more traditional roles of lead programmer or project manager boils down to responsibility. A traditional project manager is responsible for delivering a software project, for example shifting obstacles to success or building strong relationships with the project's sponsors. A traditional lead programmer is responsible for delivering the working software that the project depends upon, and has explicit software writing or designing tasks. Whereas a coach is responsible for delivering the most effective team possible given the nature and duration of the project. (Which is not to say that the coach doesn't pitch in with the team to write software - it just isn't their primary activity.)
The role of the coach was first defined in Extreme Programming but really a coach adds value to any kind of agile software development team. (And business coaches are now proposed to improve the interaction between business customers and their software teams.) XP teams in particular require a coach because XP is a high discipline process, and the coach's feedback maintains the practices on which XP relies. For more information about XP coaching see the presentation I gave at the 2002 London XP Day.

What price well-formed HTML?!

Thought I'd check whether the HTML in this blog was properly formed ('cos I care about things like that). And I find that the ad banner inserted at the top of the page is full of bad markup (see for yourself). Which means that all the 'free' blogs hosted at Blogger are badly formed - thanks to a small error by (presumably?) one HTML programmer at Google/Blogger. Who says one person can't make a difference...?

Welcome!

Welcome to Tim Bacon's blog: I'm a software developer working as an agile / xp coach for Thoughtworks in the UK. I'm lucky enough to be working with great guys who really know their stuff: folk such as Alan Francis, Joe Walnes, Geoff Oliphant, Darren Hobbs, and of course, Martin Fowler .
This is where I plan to muse about topics such as: why large projects suck, what is coaching anyway, schools of software philosophy, and being agile. Plus (providing I get my writing engine in gear!) participant reports from the likes of OT 2004, XP 2004 and Agile Development Conference.
Watch this space...