Category: Agile

Jeremy Stell-Smith’s says, in a post about Stand ups as Huddles:

I’m actually not a big fan of the traditional yesterday – today – issues format. I find that too often it becomes a status meeting – this is what I did yesterday, doing more of the same today, and no issues.

We’ve found the same thing, and tried (with limited success) to apply some of the traditional retrospective questions to the daily stand-up, so What did you do yesterday? should include What did you learn yesterday, and What’s holding you up? should include What’s still puzzling you?.

The other important thing is to jot down things you think of during the day that you want to mention at the stand-up, otherwise (particularly if you have a memory like mine) you end up going round the circle and waiting while everyone says “I’m sure I did something yesterday… let me think…”.

[tags]agile, stand-ups[/tags]

A post by Perryn Fowler reminded me of something I’d been meaning to say for a while. Perryn says:

agile is an adjective, not a noun

Saying ‘Agile Practices’ makes about as much sense as saying ‘Fast Running Shoes’.

Saying ‘Agile Best Practice’ makes about as much sense as ‘Fastest Running Shoes’.

It seems quite common (and I’m sure I’ve done it myself) to say you’re ‘doing’ agile. I think you can ‘do’ XP, Scrum or your methodology of choice, but agile has to be something you are.

So, how do you know if you are agile? I think it’s down to whether you believe in the manifesto, and more importantly whether you follow the principles.

[tags]agile[/tags]

We’ve nearly completed the process of handing responsibility for the internal system we’ve developed to an outsourced team, and I found this comment from our customer/user representative interesting:

“I have to spend so much of my time discussing how everything should work now. With the old team, I could just describe what we needed and I knew you’d understand what I meant and come up with a good solution.”

Let’s hope there’s enough continuity in the new team for them to build up a similar relationship. Of course, turnover of people (and hence depth of domain knowledge) is one more thing that you lose control of when you outsource a project.

I see Adewale Oshineye has posted some excellent photos from XP Day. Fortunately all you get to see of me is the back of my head (and hard as it may be to believe for those that know me, I’m not deliberately hiding my face in the second one!)

[tags]xpday[/tags]

Here are some notes from the recent (excellent) XP Day conference. This is based on my internal BT write-up, with a few company-specific bits removed.

An excellent post on Kill the Meeting, pointing out the insane amount of bureaucracy you end up with when writing code is treated as an unskilled production line activity.

On one recent project, the software development managers insisted on a 5-page requirements definition document, two management reviews of that document, a functional specification with four contributors, a peer review and a management review of that document, a detailed design document, a management review and sign-off of that document, and a test plan before development could begin on the code.

The code in question? Five lines of SQL.

Yes, a 2-hour project took over a month.

Some of that sounds horribly familiar from past projects. What’s the betting that the people writing and reviewing the documents could have written the code themselves in a fraction of the time they spend ‘saving money’ by contracting the work out, if only writing code wasn’t treated as a menial task to be discarded on promotion?

One issue with the conclusion though:

Unfortunately for me, I don’t think this is a process I can change here. It turns out that outsourcing development to India is so much cheaper that even if it takes four times as long, it’s still a net savings.

Even pretending that the offshore developers were free, that only holds true if the time spent in-house doing all the design, documentation and reviews was no more than eight hours, which sounds unlikely. To my mind, outsourcing software development to release your own people for ‘higher value’ work only costs in if you outsource the lot, from requirements to delivery. Otherwise you end up employing the same number of people just to keep the cheap developers on the right track.