If you see anything about LMAX - the Disruptor, Continuous Delivery, or even the selection criteria for hiring developers, you’ll see that LMAX is pretty keen on Agile. However, no-one’s documented the Agile process there, as far as I know. Although I personally had it on my todo list, I never had the motivation, the hook to do it. And I realised eventually that’s because I’m not sure it’s a process that would work very well for another team, in another company, working in another business.

On Monday, Stephen Chin from Oracle visited me at the 10gen offices as part of his NightHacking tour. In the video we talk about my sessions at JavaOne and the Agile presentation I’m giving at Devoxx, and I do some very basic hacking using the MongoDB Java driver, attempting to showcase gradle at the same time. It was a fun experience, even if it’s scary being live-streamed and recorded!

I was flattered to be interviewed for InfoQ at QCon London. It was a fun interview actually, and didn’t feel anything like the half an hour it actually took. In it, I get to talk about Agile at LMAX, the Disruptor (of course) and diversity in IT (again).

After attending a number of conferences and events, and performing numerous interviews, I’m starting to hear the same things again and again. Since Dan North challenged all my assumptions at QCon, I’m reluctant to outright ridicule them, but I will put forward my personal opinion.

Note: these are things I have heard from multiple sources, so with any luck I am not breaking the sanctity of the confessional interview.

Last week I went to get my hair cut (yes, sorry, this is a story about hair). I had thought long and hard about what I wanted. I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion. I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with. I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.

We are hiring! If you think we’re doing something interesting, or if you think you can help us do our thing even better, come join us. Your boss will be the dude who wrote Continuous Delivery, you’ll get a chance to experience what Danny calls meta-Agile (or Agile Agile), and you’ll really start to care about Domain-Driven Design. Ideally we’re after Java people, but at the heart of it we want people who are dead passionate about development.

As a survival trait for living and working in the cites¹ of London, I have a set of rituals to avoid hangovers. If you are not a single person living in a city like London, you might not understand how vital this is. Most networking, particularly in the financial services industry, is done in the presence of alcohol.

So preventing the inevitable hangover is quite important to the other part of the job – the actual working bit. I’ll let you into a secret and tell you my nightly ritual:

Having experienced Flaccid Scrum, I find this article interesting, and agree with most of it. I’d also like to add though, that if you do the scrum practices (story cards, stand ups, retrospectives, etc) but don’t buy into the fundamental principals, you will not succeed. And that means everyone on the team, not just the people in charge. In particular, if the team is not empowered, is not committing to the estimates and the iteration plan in its heart, and and does not trust, then you are probably better off using traditional processes.

This is a bloody good idea. It builds upon my own Virgoen tendancies to write lists and tick things off, but what the list model lacks is the “in progress” state. Plus occasionally my lists get confused. See today’s notebook page:

…there are a number of points in this interview with Paul Oldfield which are interesting to consider when thinking about “doing Agile right”. It seems to be compatible with my “people over process” view - I’m not stating that having good people negates the need for any form of process or discipline, I have seen that this is simply not the case. I do however think that agile techniques in particular rely heavily upon the “right” people / team, for some nebulous definition of “right”.