Categories
Agile

Fighting Developer Abuse

This ThoughtWorks recruitment ad is pure genius.

Categories
Agile BT

I guess we’re now a cool international telco

Overheard last night at XtC:

“I work for Dresdner.”

“Ah, they used to be a cool international investment bank.”

“What are we now then?”

“An international investment bank.”

“Why aren’t we cool any more?”

“Because you lost JP.”

Categories
Agile Software

The other kind of SOA

Most large organisations have been using SOA for years, and they’ve been doing it despite their IT strategy, not because of it. No, not Service-Oriented Architecture, but Spreadsheet-Oriented Architecture.

Categories
Agile

We don’t have a Lord – team leadership and decision-making

Simon Baker has posted a response to John Scumniotales’s post on Team Leadership and Self Organization, and I have to say I’m with Simon.

Categories
Agile Java

“Given when then” in JUnit

AS I mentioned at the end of this post, I’ve been convinced by Dan North’s case for using the “given when then” pattern for specifying scenarios during behaviour- or test-driven development, and while I wait for JBehave to be released, I’ve been playing around trying to come up with a way of using the pattern to clarify intent in (Java) unit/acceptance tests.

Categories
Agile

Great waterfall quote

A slightly cynical post from Kevin Barnes today – bizarrely entitled Agile processes, are they killing our children? – contains the following line:

Managers like the waterfall model for the same reasons that tourists like real waterfalls, they are simple and powerful and beautiful to look at. They are much less fun when you go down one.

I didn’t think he’d be able to top that, until I read down a little and laughed out loud:

The one group that always had mixed feelings about the waterfall model was consultants. Consultants can’t afford to show up, work for months at a time and produce no real results (unless they’re Accenture).

Categories
Agile

No satisfaction – the Toyota process

There’s an excellent article about the Toyota process on fastcompany.com. Most of the behaviours described are also desirable or necessary in teams or organisations trying to be[come] agile, but the key point is in the conclusion:

Categories
Agile BT

The death of the Big Blue Notebook

No lab books!
Ever since I started work, people have had big blue (or more recently black and red) books that they wrote stuff in. I’ve always called them lab books, but that seems to cause amusement to some people, presumably because I don’t work in a lab.

Some of the things that were written were notes from meetings, to do lists, or rough design notes. The most important ones though, the ones that you kept referring back to (if you could find them), were the little snippets of secret knowledge that everyone accumulates as they learn the intricacies of their particular job, whether it’s useful unix commands or instructions for using a particular build system.

Categories
Agile

Personal whiteboards

Agile teams tend to favour whiteboards for instant collaboration when discussing design etc, but if you’re working in a pair you might not always want to keep walking over to one on the wall. The answer? A4 whiteboards!

They only cost a couple of pounds each (including a pen), and at the risk of attracting ‘XP isn’t for grown-ups’ comments, the best place to buy these seems to be primary school suppliers – for example Class Ideas or EasyTeach. At that price, you may as well have two or three each.

[tags]agile, tools[/tags]

Categories
Agile BT Rants

Agile in the enterprise: don’t try to steer the supertanker

When people talk about large organisations making major changes to their core processes or values, sooner or later someone will compare the process to steering a supertanker – if you turn the wheel now, you’ll have travelled quite a distance before there’s any noticable change in course.

This analogy falls down when you’re trying to introduce agile software development. If you want to be agile, a supertanker just won’t do the job any more. It’s time for small teams to jump into the lifeboats and set off in their own directions, leaving the heavy old legacy systems to continue their progress on their predictable course. The lifeboats are far nimbler and can react much quicker to changing conditions. Of course (and that sound you hear is the analogy stretching close to breaking point) they would still be in radio contact with the captain, so you wouldn’t lose sight of the overall strategy.

Personally, the lifeboat I was in until Christmas now has a new crew and is sailing under a flag of convenience out of Mumbai. I have no idea what I’ll be doing in the new year, or whether we’ll remain as a team, but at the moment it feels very much like we’re being dumped back on the supertanker, and while we’ve been off charting new territories, the ship’s only turned by a degree or two.

[tags]agile, enterprise[/tags]