Don’t forget the developers!

I visit numerous organisations that are implementing “agile transformations”. In many of them I see a familiar pattern:

The managers and business analysts are sent on courses and sent to conferences and given books to read; most of them change their job title to things like Scrum Master or Product Owner; they create their plans using “stories” written on post-it notes, and they organise their projects into Sprints. But only rarely does anyone help the developers change too.

These organisations have cargo cults. The developers and the testers have at least as much to learn, and need as much support as do the managers and business analysts.

In order to deliver a working product increment every two weeks, indeed to work at all effectively in an agile way, programmers need to learn a whole raft of new skills and modes of thought. Continuous delivery, emergent design, test-driven development, pair programming, mob programming, feature slicing, YAGNI, outside-in development, … The list is long; and most of the skills on it can seem at best counter-intuitive to those who have grown up working in the “old ways”.

Agile methods arose from the realisation that the creation of working software should be at the centre of everything, with all other activities subordinated (in the Theory of Constraints sense) to it. And yet I see so many organisations in which the agile transformation stops with the introduction of stand-ups, plans written on post-it notes, and maybe some 3-amigo training for the BAs.

If your agile transformation is focusing on the way execs measure ROI, or on how project plans are written, or even on how teams are managed, you may be missing out on the biggest throughput boost of all: supporting your developers in coping with this whole paradigm shift.

Of course you will get some improvements in throughput by slicing your plans into frequent releases and focusing on maximising value early etc. But it will never really get flying if your developers are still thinking in BDUF terms, integrating late, leaving the testing to be done by someone else later, hoarding knowledge, collecting technical debt, building systems in horizontal layers, relying on the debugger etc etc. Many developers only know how to work this way; many see the XP practices as counter-intuitive, if they’ve even heard of them.

So when you’re considering implementing an agile transformation in your organisation, please remember that it’s all about software development. Without the programming activities, you would have nothing to manage. Make sure to give the programmers enough support so that they can learn to work in a way that fits with and supports and enhances your agile transformation. Find someone who can teach them the XP practices and mentor them through the first 6 months of their adoption. Because if you don’t, the very thing that agile is about – programming – will hold back, nay derail, your agile transformation.

Update, 20 Oct 17

I used this blog post as the basis of a lightning talk at LeanAgile Manchester last night. My slides (without animations) are here.

Estimating user stories: the 5 day challenge

This is a quick note about an idea I’ve been using with a few software teams during the last couple of years. I also spoke about it briefly at the Scottish Ruby Conference this week (video at the bottom of this post). If you try it, please publish your experiences and link to them via the comments here.

TL;DR — don’t guess the size of a story; fit the story to the size you want.

Continue reading

interviewed at scottish ruby conf

Way back in March of this year, while I was attending the Scottish Ruby Conference, Werner Schuster interviewed me for InfoQ. The video has been online since August, and this is me finally getting around to telling you about it; watch it here. I talk about Reek, Refactoring in Ruby, and agile development in general.

This was the first time I’ve done a video interview, so I’m keen to hear your comments on how it went!

geekup nottingham

Tomorrow evening (Nov 1st, 2010) I’ll be speaking at GeekUp Nottingham, reprising my flow session from this year’s AgileNorth conference. And at some point in the evening I’ll be giving away a signed copy of my book Refactoring in Ruby.

If I show slides tomorrow, it’ll be the set I showed at AgileNorth, plus a couple I’ve added just in case there’s no flipchart.

Looking forward to a great night, and to fascinating discussion as always.

releasing vs delivering

Here’s a quick thought that you might like to use in your next retrospective: Do you know that the software you just released has realised the expected value?

What if the answer is that you don’t know? How could you find out? And what might be the positive or negative side-effects of going to find out?

Here’s another way to look at the same question: Do you deliver more value by moving to the next story/MMF, or by helping the current story/MMF to release its full potential? Is there a single answer for your software/service? If not, what factors or conditions would cause the answer to change?