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
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.
As a survival trait for living and working in the cites1 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. Or just as likely to fail whatever process you use.
I think the statement that struck me the most when I was on the Certified Scrum Master course was:
The start of the project is when you know the least about what you're doing
Which of course is absolutely true.
So why do we come up with extensive requirements, detailed design, and fixed plans at this point of time? We haven't put anything into place yet, we haven't played with the code, the customer hasn't seen anything of what we're promising to deliver.