Speaker Details

James Birnie


James has worked in software since the 1990s, when TDD was something you studied but never did, Agile and Lean were words used to describe athletes and pipelines were for carrying oil. After working in a startup for 9 years he started a new life as a consultant and now spends his working days at Codurance trying (and occasionally succeeding) to effect positive organisational change through enabling others to deliver high quality products.

Agile is STILL A Dirty Word

Methodology & Culture

Last year at Devoxx UK I presented "Agile is a Dirty Word". It started at Devoxx Belgium then took on a life of its own as it became my most consistently successful and enjoyable talk with a mixture of dry humour, real life anecdotes and tales of dysfunctional business that every audience can relate to.

When I first gave that talk it was intended as a bit of a lament against all the bad implementations of Agile that I've come across in my career as a consultant and I touched upon a couple of techniques that I was experimenting with at the time.

A year on and I have put into practice some of my own suggested techniques and I've been involved in some stunningly successful transformation work.

This talk is not just a lament against dysfunction (although there will be a bit of that still) but it is now a playbook of practical steps that can be used to effect lasting change in any organisation.


Do you really NEED that estimate?

Byte Size
Methodology & Culture

We are often asked as software professionals to estimate, usually with a laughable level of precision, the time for a whole product at the very time that we have the least idea how long it could possibly take. Unsurprisingly these estimates don't turn out to be very accurate. Why do people think they need these estimates? What value do they think they get from them? In my entire 20+ year career in software delivery I have rarely seen estimates used positively, for example to help inform a business plan. I have only ever seen them used negatively, as a kind of post hoc pseudo contract that the development team inevitably broke. In this talk I will explain what I think are the only times that estimation is justified and what you can do to prevent getting forced into a binding contract that you not only didn't sign but that you didn't realise even existed.

Development Methodologies