Trisha's Ramblings

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. The agile process followed at LMAX is one that works for the individuals and the organisation there.  And that's because they do one thing very well - they regularly examine the issues faced and adapt the process to try and combat them.  It's an agile process that's, well, very agile - it's constantly changing.  Documenting it would only represent a single snapshot in time that would be out of date almost as soon as the next retrospective comes along....

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. I've never pair programmed, but I've frequently worked with a partner on critical production problems I find this fascinating.  If there's one thing that needs to be fixed as fast, as correctly, as efficiently as possible, it's a production issue.  And when there is one, "everyone" knows that two heads are better than one, even The Business. If this is the case, why is it so hard to sell pair programming as the default state of affairs? Is it because creating new features is seen as just typing, where the bottleneck is access t...

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. He did an excellent job.  It was almost exactly what I had asked for, with some variations to account for my particular hair type.  It was a very cute hair style that suited me.  But I had a niggling doubt. A few days later, that niggle was a certainty.  It wasn't what I wanted. However, it was what I had asked for. Being English, the thought of going back and telling him I wasn't happy with it was horrifying.  Especially sinc...

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. Apply via the Stack Overflow Careers advert  (you get extra brownie points if you mention my blog).

As a survival trait for living and working in the cites 1 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: Floss and clean teeth (OK I'll admit, I barely floss when I'm sober let alone drunk) Cleanse/tone/moisturise (I'm a rubbish girl, this is a very recent ritual for me) Apply cuticle cream Do my calf stretches Drink 500ml of water Eat something, even if it's a dirty McDonalds (quarter pounder with cheese, no pickle no onion). Prior to all this is the additional requirement “don't drink more than a bottle and a half of wine”. Everyone has their limits, lots of practi...

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

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: Thursday Fix bugs in Test Director Merge fixes up Do build Merge down Read terms of contract E-mail solicitor Go to Robert Dyas Order DAB Radio Finish business analysis docs Carry on with QCon note consolidation How do I know which ones I've started? I could do with a couple of boards at least as well to separate the personal from the business. Also note that I took something away from my Time Management course, attended when I was a mere graduate at a large manufacturing organisation: make a new list for each day, discarding your completed items and moving forward the incomplete ones (it also mentions to discard "low priority" items that haven't been done over a week or two under the theory that you'll never do it if ...

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