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.

5 thoughts on “Don’t forget the developers!

  1. Pingback: Java Web Weekly, Issue 146 | Baeldung

  2. Sounds like that would make an excellent talk Kevin, sorry I missed it.

    I was surprised to read that organisations try to become agile by training everybody but the developers. Now you’ve said it I can imagine how it can happen, but it sounds odd to me (I’ve never witnessed it, but then I don’t get hired to help people implement agile, and tend to work with teams that already get it).

    This focus on non-tech training suggests that agile is being introduced by people who aren’t in a position to understand it, but for some reason believe they need it? Is that right, and does it basically boil down to fashion (i.e. they’ve heard about it, it must be good because everybody’s talking about it, so they want it)?

  3. Hi Graham, I’ll be doing the same session a bunch of times at meetups around the north, so look out for announcements in the coming weeks.

    After the talk a number of people came up to me and said that their company was in exactly that situation, so it isn’t a rare thing. I think you’re right that some organisations “do Agile” thinking it’s simply a better way of herding programmers, or thinking that it’s a good badge to have on their letterhead.

    And then of course there’s Scrum, whose original literature could be read as implying that sprints are mostly a planning tool…

    • It’s still amazing me. Getting into these companies and helping them see what they could achieve sounds like a relatively easy way to add a huge amount of value (which I suppose is exactly what you do).

      I’d always imagined the big challenge would be getting buy-in from management and non-technical people, who don’t see the point in getting involved (e.g. on-site customer, writing stories together, etc). Those are the only areas in which I’ve encountered any initial resistance.

      Perhaps I’ve just been filtering all the other companies out as a side effect of how I’ve chosen who to work with (i.e. teams that get it).

      • “sounds like a relatively easy way to add a huge amount of value” — Unfortunately adopting the XP practices can be far from easy. Especially when compared with how easy it is to introduce sprints (that don’t deliver working increments) or standups (which serve merely as a different reporting ceremony) or postits (which document the paragraphs in the requirements spec).

        Cargo cult Agile is everywhere. Actually delivering working software frequently, to a sustainable pace, is orders of magnitude harder than moving the furniture around.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s