Agile++: When Agile Goes Well

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.

Any process can inspire Cargo Cultism, and the last thing I want to do is give people a process to without the tools to know whether it’s the right thing for them or not.  It’s more important to understand your goals, check progress and improve.

I was talking this through with a colleague, Israel, and he rightly pointed out the tool that LMAX can share with everyone else - thinking.  Examining the problems, visualising them, and trying out different ways to fix them.

So at Devoxx Israel and I presented a session on “Agile++”, using LMAX as a use case of when agile methods work.  The session examines four specific issues encountered at LMAX and the steps taken to solve them, and it’s available on Parleys.  Enjoy.

Overheard: Agile truths

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 to the physical keyboard?  Is it because fixing defects when the pressure isn’t on is suddenly easier for one person on their own without help?

This state of affairs is interesting to me as it implies that when proverbial hits the fan, the instinctive thing to do is to work collaboratively.  Why don’t we do it more often?

We use Test Driven Development to get coverage
Seems weird to me to write your tests first to get coverage.  If unit test coverage is your most important metric (and other people have covered why this might not be the case), I’m not sure why you would write your tests first.  Seems to me that you’d get better coverage writing the tests after the code.  That way you can be sure you’ve covered every eventuality.

To me, the statement implies two assumptions which I would challenge:
a) The primary value of writing your tests first is to meet your coverage requirements
b) Coverage is a meaningful metric

TDD/BDD has a number of benefits (…and now I’m reluctant to list them here in case people repeat them back to me in an interview).  Good coverage will probably be a side effect of being forced to write your tests first, but I’m not convinced that’s the best thing that will come out of using TDD.

I only test first when I know what I want to code
I’ve overheard people saying that they test first when they know what the code is going to look like.  So you dive straight into the code when you don’t know what you’re doing???

Of course there is a place for this - spikes, prototyping, getting a feel for a new library, so on and so forth.  But I feel that for most code that you write in your day job, you probably have a business requirement and possibly (probably?) a less firm idea of how you’re going to code it.  To me, this translates into writing the test first (which documents what you want to deliver, which you already know) and then getting that to pass (which is writing the code, which is the bit you might not know).

If you know exactly what the code is going to look like a) I would question that statement and b) what’s the point of the test?

What are the real answers?
At QCon I saw on Twitter a number of complaints because the presentations there gave opinions, guidelines, and, worst of all, a lot of “it depends”.  But people seemed to want The Answers.

In my opinion, what developers get paid for is working out the “it depends” parameters and selecting an approach, technical or process-wise, that works for their situation.

So although I have strong opinions on all the above subjects, and although LMAX has specific approaches to both pair programming and automated testing, sadly I’m not going to go into lots of details about those.

Mostly because I’m still interviewing candidates, and I don’t want to give away the correct answers….

Why the customer isn’t always right

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 since he had done a really good job of it.  It wasn’t his fault that what I’d asked for wasn’t what I had actually wanted.  But I knew what I wanted now, and I was prepared to pay for it (again).

This time I didn’t show him a picture.  I didn’t point to anything specific.  I said I wanted it much shorter after all and outlined the look I was going for.  We had a conversation about it and I left it to him to apply his skills to actually implement it.

This time, I was much happier with the results.  In fact, it was exactly what I wanted.

So what?

Of course this got me thinking about work.  It’s not just a lame excuse to write about girl stuff on a supposedly technical blog.  It got me thinking about our customers.

Whoever our customers are, whether they’re end users, internal business owners, external clients, or we work in a bank and have fifteen thousand layers of Business Analysts between us and Real People, whoever they are they want something from us.  And in many places, we, the techies, have trained them to ask for more and more specific things, so they can be sure they’re going to get what they really want.  Remember that time Bob asked for that extra field on that report because it would make his job easier?  Remember when Sandra wanted the workflow to be altered in a specific way?  It’s because they know that if they ask for something specific, the chances are better that it will make its way to the front of the work queue at some point, and when it comes out the other end it is more likely to be what they wanted.

Only it isn’t, is it?

There’s always another field to add, or another change to make.  And your customer isn’t quite satisfied, even though you did exactly what they asked for.  And sometimes they don’t tell you that they’re not getting what they need from your system, because it’s expensive or time consuming to get changes made.

The key to delivering something they really want, instead of something else that’s merely adding to the weight of your code, is finding out what they’re actually trying to achieve.

So Bob wants that extra field.  That’s easy enough.  But when you ask him why he wants that extra field, turns out it’s because the numbers in the reports he’s getting at the moment aren’t the ones he needs, or aren’t quite correct.  He’s probably created a monstrous Excel spreadsheet into which he manually types half of the numbers from the reports it took you ages to develop, which munges them into something quite different, in order to get the real thing he wants.  He’s just missing this one small piece of information to get the final figure correct.  It would save your company a lot of time/money/mis-typing errors if you completely re-wrote the reports Bob uses to give him exactly what he needs.  Or if you gave him a tool to download CSV formatted raw data from the database.

It’s not Bob’s fault he can’t ask for this, he doesn’t know what we’re capable of providing him.  It’s not our fault for not delivering it the first time round, we don’t know what he does day-to-day.  But having a conversation where we recognise where the knowledge lies (Bob knows what the output of his day job is presumably, and we know what’s available and how we can provide it), and collaborating to come up with the least rubbish solution for everyone, is a step to providing that overused term, “business value”.

We’re not on different sides here, we all play for the same team - we want our jobs to be as painless as possible, which (should) ultimately provide better efficiency for our company.  After all, we want the company to make money so they can pay us, right?

<span style="font-size: x-small;">Caveat: Mileage may vary.  Sometimes, with some customers, you really do need to tell them what they want.

Are you an awesome developer?

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<img alt="" border="0" height="1" src="http://www.assoc-amazon.com/e/ir?t=trissramb-20&amp;l=as2&amp;o=1&amp;a=0321125215&amp;camp=217145&amp;creative=399377&#34; style="border: none !important; margin: 0px !important;" width="1" />.

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

What my hangovers can teach you about Agile

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:

  • 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 practice means I know full well what mine are.

This actually works for me. I won’t claim to feel capable of being quite as high performance as the code I’m working on, but I won’t feel like killing myself, and I will make it to the gym before work and do a whole day of productive coding.

If you were trying to solve a similar problem (“no debilitating hangovers”), you might try and follow my rituals. But you might decide that drinking the water was going to mean you had to go to the loo in the night, and strike that off the list. You might be on a diet, so you don’t have the food, thinking the alcohol is calories enough for the night. And you’ll follow everything else religiously, but still have hangovers.

Or you might ignore the alcohol intake guidelines, thinking the stuff that you do at home to repair the damage should be enough, and drink 12 pints of margaritas. Or you might be the sort of person who can only get away with drinking a couple of glasses of wine / pints of beer, and follow my rules perfectly, but still feel like dying the next day.

And when this happens you’ll look at my rituals and think “What a waste of time! This person has no idea what they’re talking about”, and throw the whole lot out of the window and go back to doing waterfall development (oh wait, I’m getting ahead of myself).

Or you’ll do the bits that actually prevent the hangover (the water, the food, restricting alchol) and go around telling the interweb I have no idea what I’m talking about because the other stuff is a waste of time.

The key point here is that this works for me. It’s foolish of me to tell the world this will fix all their problems, and pointless for others to copy it without realising why they’re doing it.

For example – why on Earth is “apply cuticle cream” on there? It doesn’t actually fix the problem of dehydration due to excessive alcohol intake. But it’s important to me, because I need to make the time to do the whole ritual to get my brain into the right place for sleep. It’s also dead important for my subconscious – alcohol is basically abuse of my body, the beauty part of the regime is to remind my brain that its important to take care of myself too. It doesn’t fix the immediate issue of hangover the next day, but it aims to prevent future problems of drowning my sorrows in alcohol. It’s an important part of my Long Term Plan – these rituals need to be worked into the daily steps to lead eventually to World Domination.

And calf stretches? Well, I’m injured, have had shin splints for a million years. If I want to run the Royal Parks Half Marathon in October, I need to stretch 3 times a day. Doesn’t matter if I’m drunk or not, it’s not an excuse. The half marathon is a very important longer-term goal. But you don’t need to do it. Well, unless you have the same issue.

The important thing is that all of these rituals are tied to a goal.  But they’re not the same goal:

  • Floss and clean teeth. GOAL – don’t get told off by the dentist. Don’t require fillings - costs money and not great for overall health.
  • Cleanse/tone/moisturise. GOAL – prepare subconscious for sleep and remind brain that body needs love.
  • Apply cuticle cream. GOAL – prepare subconscious for sleep and remind brain that body needs love.
  • Do my calf stretches GOAL – Royal Parks Half Marathon
  • Drink 500ml of water GOAL – prevent Debilitating Hangover
  • Eat something, even if it’s a dirty McDonalds GOAL – prevent Debilitating Hangover.

The thing here is that if I didn’t do the stuff to aim towards longer-term goals, I might be more inclined to drink more out of boredom or despair, I might have worse hangovers in the future.

To paraphrase Eddie Izzard “…and that’s like our Lord Jesus the agile process…”. Agile, in whatever form you take it (actually all processes) is supposed to enable you as a team / organisation to work better. Whichever cult you follow, there are practices designed to work for you to make you more productive. But you do have to continuously improve, gather and act on feedback, and, most importantly, to know why you’re doing what you’re doing. Otherwise it’s just cargo cultism – you look like you’re doing everything, but the results just don’t arrive. I’ve worked for a scrum-but company – they had the cards, short iterations, invested customers.  But no single product owner, they never acted on the results of retrospectives, and most importantly the team didn’t own the work they’d signed up to. They also had a project manager who told people what they were doing. This doesn’t answer the question. This is drinking 12 pints of scrumpy and doing “cleanse/tone/moisturise”, and wondering why it still hurts.

You have to understand the problem. You can’t blindly follow the stuff that you fancy, the stuff you find easy. If it’s easy, it’s probably something you were already doing.  If you picked up agile to make a change to deliver more/better/faster, there is going to be some pain. Because if what you were doing before was working, you’d carry on doing it. So improvement is going to be hard. At first.

The key is to stick with it, to check progress, to continuously improve. To find what works for you.

1 Random fact of the day: London is actually two cities, the City of London and the City of Westminster.  But you probably already knew that.

Scrum but…

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.

Agile Infection Growing

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 you haven’t by then).  This is great for keeping a nice clean list of achievable goals for the day, but a bit rubbish at giving any positive feedback - no matter how much you get done, every day there’s yet more to do, and lack of visibility on what you have actually achieved. The example story wall in the link above is great for a sense of acheivement - yes there’s still things to be done but look how much has been achieved in comparison!

However, I am going to make the common criticism of cards: one of their major advantages, their “physicality"1, is also the disadvantage - whilst I can take my little notebook round with me, I can’t lug a story wall between work and home. And although some of those things are personal tasks, they need to be done at work (e.g. e-mailing because I haven’t got my broadband at home yet) or between work and home.

Mind you, I actually have 3 pieces of paper containing lists of things to do / buy / check / clean with regards to my new flat, because of my inability to actually carry the notebook with me.  Or the same one at least.

I think this means two more items to be added to the “To Buy” list: a magnetic whiteboard and some story cards. I like whiteboards because you can even scribble stuff behind / around the cards.

EDIT: Bah, someone else already beat me to it.

1 This is an extract from James Shore’s section on Stories:

Write stories on index cards.

This isn’t the result of some strange Ludditian urge on the part of XP’s creators—it’s a deliberate choice based on the strengths of the medium. You see, physical cards have one feature that no conglomeration of pixels has: you can pick them up and move them around. They’re tactile. This gives them power.