All Philosophy, No Practices

In my current project, I'm talking up the XP Philosophy without being able to follow any of the XP Practices. This is how it's working out.

Courage, Simplicity, Feedback and Communication.

Courage was almost instantaneous. The project was veering towards a Death March. I asked the Gold Owner when he wanted it ready to show it to his customers. He said twelve weeks. All I did was to convince the team that this was a deadline worth working to – anything is better than the open-ended march. Sure, scope negotiation became a key issue for a week or two, but only that much. Everyone wants to meet that deadline, and I just “encouraged” them. The next step will be to get the Gold Owner to have the courage to present the product confidently to customers and be convincing about why it’s worth the money. That’s for next month.

“You are a good programmer, but you never listen” said a colleague to me. Notice that I did hear what he said, so I can’t be quite as bad as all that. But communication is an issue; a team gets into a way of communicating, and whether it’s good or bad they stick with it. I don’t. For me it’s all about face-to-face little chats, as often as possible, in a setting that’s most likely to get a shared conclusion. So the team used the internal phone system, but I use the stairs. The team used a bug tracking system, I scribble on flip charts. I’m not saying that my way is better; but if the entrenched methods aren’t working then communicate in the simplest way, which is just a matter of strolling over to a colleague’s desk, smile, ask for a few minutes of time, and then take no more than that. Smile again, say thank you, you’re done.

Simplicity? We have a database layer written using interfaces to allow a new database storage method “later”. We have a naming convention so Product.Business is two things – a project in it’s own right and a sub-directory within the Product project. We have spectacularly “generalised” code for data import which I can’t get to import anything. It all works, but simple it ain’t. However, I’m seeing a few changes. My first fight with a team like this is about not using the debugger. My second fight is wanting to run the code through NUnit. I’m delighted to see that one of the programmers has noticed how much time he saves by doing this, that it is simpler and quicker to work in this way. The current challenge is about new features. One colleague wants to add an Excel API, another wants to rewrite the reporting protocol. Both would take weeks. I’m pushing them towards a simple interface with a spreadsheet, a step-by-step improvement of the reporting. We’ll see whether banning the complex (which I have) makes them find a simpler path.

Writing this makes me realise that Feedback is the challenge. Downstairs from the programmers are the testers. They find an issue and log it in the bug tracking system. The programmers feel they don’t have enough detail. The testers feel the bug shouldn’t have occurred in the first place. The feedback loop is all wrong. We’ll have to fix that. I could work on making the automated tests more helpful – they’re broken in all the usual ways. But the simpler thing is probably to become a one-man feedback mechanism, spending my time running the code, automating where possible but not worrying when I can’t.