Agile methods in a two-person software shop

When the two of us registered the business with an ABN and signed the lease on a converted terrace in Carlton, we had a single shared belief: the work had to be honest, the code had to stay small, and our customer had to see what we were doing while we were doing it. That conviction pushed us towards agile methods long before the practice had a settled name in the local scene. We were a tiny operation — a programmer and a designer-developer — running out of a back office in inner Melbourne with two desks and a whiteboard stretched across the south wall.

The decision to iterate rather than run months-long waterfall phases was less a manifesto than a practical answer to an ordinary problem. Our first paying client was a family-run distributor in Brisbane who needed inventory software before the end of financial year. With a crew of two, no buffer of unused staff, and very little capital to absorb a missed deadline, we could not afford to discover three months in that we had built the wrong thing. Short cycles, frequent reviews, and a working build every week became the only sensible rhythm.

This is a record of what that rhythm felt like in 2005 and 2006 — the morning meetings for an audience of two, the pair sessions that crossed Sydney and Melbourne via screen share, the retrospectives held over flat whites on Gertrude Street, and the ceremonies we kept, and the ones we quietly dropped. Most of what follows comes from memory and from the Subversion log files we still have on an old LaCie drive in a cupboard in Sunshine.

Setting up the workshop

We chose Carlton because the rent on Nicholson Street was survivable on two days of client work a week, and the tram took twenty minutes to the State Library of Victoria, where we met readers who didn't mind talking about small business. The workshop itself was a single long room with a sash window that rattled when the wind came up from the bay. My partner took the desk closest to the window because she needed daylight for interface work; I took the back desk because I needed quiet. Between us stood the whiteboard, which doubled as a planning surface, a status board, and on a few evenings, a passive-aggressive record of who had left the dishes in the sink.

The toolset was modest. Source control lived on a self-hosted Subversion repository on an old desktop tower, with a Trac instance bolted on top for issue tracking, wiki pages, and a timeline view. We supplemented Trac with a small Bugzilla mirror for the federal government client we picked up in our second quarter, because the information security folks in Canberra would not entertain the idea of putting official records outside the corporate shortlist. For chat we used IRC on a server hosted with Pipex in Sydney; the latency across the eastern seaboard was barely noticeable. Basecamp handled client-visible to-do lists because at the time it was the only product that let a non-technical customer in Brisbane feel like a participant.

A 2005 Australian dollar did not stretch quite as far in software as it would a few years later, and we could not justify spend on tools that did not earn their keep within a fortnight. Subversion, Trac, Bugzilla, IRC, and Basecamp all passed.

Daily stand-ups for two

The idea of a daily stand-up in a two-person shop sounds faintly ridiculous, and the first time we did it I suspect we both felt the same way. There was no-one to report to, no manager waiting for status, and the blockers were usually a missing library, a corrupt checkout, or the barista next door. We kept the meeting anyway, because the discipline turned out to be useful in a way we had not predicted: it forced us to say out loud what each of us was actually working on, and that conversation exposed dependencies we had each assumed the other was handling.

Our stand-up ran for ten minutes at 9:15 in front of the whiteboard. Three questions, in the same order every morning: what did you finish yesterday, what are you starting today, what is in your way. The answers were written on the board in red marker, photographed with an old Olympus, and uploaded to a private Trac wiki page so we could scan the history at retrospective time. On days when the work was genuinely on track, the whole thing ran shorter than the kettle took to boil. On days when one of us was blocked, standing up was an excuse to sit down and stay seated.

When my partner spent six weeks in Sydney helping her sister with a new baby, the stand-up moved online. We would log in over a thin ADSL link at 7:45 her time, scribble on a shared whiteboard in TuxPaint, and treat the ceremony as if we were in the same room. The discipline of speaking — even to a webcam perched on a borrowed monitor — kept us honest. It would have been easy, with one of us in Sydney and the other in Carlton, to drift into a sequence of friendly emails that told each other nothing useful. The stand-up was the antidote.

Pair programming across the eastern seaboard

Pair programming in a team of two sounds, again, almost redundant. Surely two people on the same screen will produce, on average, half as much as two people on two screens? We measured it by logging time against feature branches in Subversion and tracking rough velocity through Trac. After three months pairing had cost us about twenty per cent of raw typing throughput. After six months we shipped roughly thirty per cent fewer bugs that came back from the Brisbane customer, and far fewer that came back from the Office of the Commonwealth Inspector-General.

Our setup was straightforward. We used a shared desktop on the LAN most days: one of us at the keyboard, one at the whiteboard sketching what the test was going to look like. The driver typed, the navigator talked. We swapped roles on a kitchen timer that rang every fifteen minutes because anything longer and the navigator drifted into email. When my partner was in Sydney we ran the same pattern over NetMeeting and a pair of headphones, which was almost as good; the latency on the Sydney–Melbourne link was about thirty milliseconds, so the only thing we missed was the whiteboarding.

The pairing changed the texture of the workweek. There were afternoons — we called them arvo sessions, a term that refuses to leave the local vocabulary — when one of us struggled to articulate a thought and the other lost patience. We learned to call a break, walk down to the bakery on Lygon Street, and come back twenty minutes later with a different frame on the problem. The flat whites there became, in time, our unofficial paired-programming coffee of record.

Short iterations and honest backlogs

Two-week iterations gave us a heartbeat short enough to recover from mistakes. Anything longer and a missed assumption would silently compound; anything shorter and we would spend the whole time planning. We agreed on fourteen days, and that became the unit of accounting the customer in Brisbane understood. Backlog items were written on index cards in plain English, taped to the wall beside the whiteboard, and copied into Trac every Friday afternoon. We did not dress them up as user stories; we wrote what the system had to do, in two or three sentences, with the customer as the subject.

Involving the customer meant a thirty-minute call at the start of every iteration and a working demo at the end. The customer, who owned a wholesale produce business on the south side of Brisbane and was busy with mango season in November and January, gave us roughly an hour of his time each cycle. We learned to prepare the demo so it could be cut short if he had to take a call from a freight forwarder, or extended if a feature had surprised him. He never asked about burndown charts or velocity numbers; he asked whether the end-of-month stocktake screen would be ready by the fifteenth.

The discipline of the iteration gave us permission to say no. Items that did not fit on the wall by Friday afternoon went into a manila folder under the desk, which we reviewed each quarter and mostly emptied. The folder was the closest thing we had to a roadmap, and the ABN paperwork sat on top.

Retrospectives without blame

A retrospective in a two-person shop could easily turn into either a gripe session or a polite silence. We borrowed a format from a Sydney XP group we had visited once, in a hall above a pub in Surry Hills: each person wrote one card per topic under the headings "kept", "more of", "less of", and "stopped". We spread the cards on a café table at the end of each iteration, in a coffee shop on Gertrude Street that has since become an optometrist chain. We bought two flat whites and a single shared slice of cake, and read the cards aloud.

The headings did the heavy lifting. "Kept" forced us to name what was working even when the iteration had been hard. "More of" pushed us towards experiments rather than complaints. "Less of" and especially "stopped" were uncomfortable, but the format made them easier to swallow than a direct accusation. When my partner wrote, in late 2005, that we should "stop pretending that bug counts are a useful number", she was right, and the conversation that followed was the closest we came to refactoring our process on the spot.

Looking back through the cards we kept, I was surprised how rarely the retrospective surfaced a genuine disagreement. Writing and reading aloud, followed by a slow walk along Brunswick Street back to the office, tended to drain the heat out of whatever had been simmering. By the time we sat down at our desks, the next plan was already obvious.

What we kept and what we let go

Looking back across the eighteen months covered by our Subversion log, the things we kept were almost embarrassingly ordinary. Daily stand-ups, two-week iterations, retrospectives, pair sessions, a working build every week, a customer who saw the demo every fortnight. None of it was clever. All of it was light enough for a team of two to carry.

The ceremonies we let go of were more interesting. Planning poker, with a deck borrowed from the Sydney group, collapsed into a coin flip with only two players. We abandoned formal velocity calculations after three iterations because the numbers jittered too much. We wrote a coding-standards document once, lost interest inside a fortnight, and let the code itself be the standard. We never did Scrum certification, partly because it did not yet exist meaningfully in Australia and partly because paying to call ourselves by a name felt a strange thing to do.

If a friend in a similar shop asked what was worth the trouble, three things come to mind: keep the daily conversation, even when it feels theatrical; keep the customer in the room, even when the room is a phone line to a mango wholesaler in Brisbane; keep the retrospective brief, and let it happen in a place with good coffee. The rest can be worked out as the work goes.