I spent last week at the Agile 2010 Conference. It was my first time at a conference this size; I definitely found it interesting and there were some thought provoking sessions – but there weren’t many deeply technical talks. As others have asked, what happened to the programmers?
Bob Martin wrote that
Programmers started the agile movement to get closer to customers not project managers
He also commented on how few talks were about programming
< 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?
People have already commented on how cost is a factor in attending a conference like this – especially for those of us outside the US who have expensive flights to contend with, too. This is certainly a factor, but I wonder if this is the real problem?
Do developers attend a conference like Agile 2010 to improve their craft? How much can you cover in a 90 minute session? Sure, you can get an introduction to a new topic – but how much detail can you get into? Isn’t learning the craft fundamentally a practical task? You need hands on experience and feedback to really learn. In a short session with a 100+ people are you actually gonna improve your craft?
Take TDD as an arbitrary example. The basic idea can be explained fairly quickly. A 90 minute session can give you a good introduction and some hands on experience – but to really grok the idea, to really see the benefit, you need to see it applied to the real world and take it back to the day job. I think the same applies to any technical talk – if its interesting enough to be challenging, 90 minutes isn’t going to do it justice.
This is exacerbated by agile being such a broad church; there were developers specialising in Java, C#, Ruby and a host of other languages. Its difficult to pitch a technical talk that’s challenging and interesting that doesn’t turn off the majority of developers that don’t use your chosen language.
That’s not to say a conference like Agile 2010 isn’t valuable, and I’m intrigued to see where XP Universe 2011 gets to. However, I think the work that Jason Gorman is doing on Software Craftsmanship, for example, is a more successful format for technical learning – but this is focused clearly on the technical, rather than improving our software delivery process.
Isn’t the problem that Agile isn’t about programming? It is – or at least has become – management science. Agile is a way of managing software projects, of structuring organisations, of engaging with customers – aiming to deliver incremental value as quickly as possible. Nothing in this dictates technical practices or technologies. Sure, XP has some things to say about practices; but scrum, lean, kanban et al are much more about the processes and principles than specific technical approaches.
Aren’t the biggest problems with making our workplaces more agile – and in fact the biggest problems in software engineering in general – management ones, not development ones? Its pretty rare to find a developer that tells you TDD is bad, that refactoring makes code worse, that continuous integration is a waste of time, that OOD leads to worse software. But its pretty common to find customers that want the moon on a stick, and want it yesterday; managers that value individual efficiency over team effectiveness, that create distinct functional teams and hinder communication.
There is always more for us to learn; we’re improving our craft all the time. But I don’t believe the biggest problems in software are the developers. Its more common for a developer to complain about the number of meetings they’re asked to attend, than the standard of code written by their peers.
Peers can be educated, crap management abides.
Actively Lazy 
I totally agree that the biggest problems in ‘Agile’ is the people problems.
When i learned about this ‘Agile’ stuff (pretty late in the game: 2006-2007) i quickly determined, for me, that the hard part of the new way of doing things, was not the programming, but the ‘people issues’.
In going to Agile2009 (i could not afford Agile2010) i focused on those sorts of things. How could I, myself, be more ‘Agile’ and how could I help my team/company be more ‘Agile’.
Now, i am trying to balance the two. I want to become better technically (my participation in ‘software crafstmanship’ both locally (boston) and bigger (going to SCNA 2009 & SCNA 2010)) and with people issues (wishing i could go to Agile2010 and my local ‘Agile Bazaar’ meetings for networking/tips).
I also agree that a 90ish minute session may not be conducive to learning much in the way of technical skills. But if the teaching is kept at a high enough level (e.g. “Integration Tests are a Scam”) then it can be quite good.
I think your point that ‘Agile’ might be, at its base, a management thing is valid. XP seems to give technical practices as a way of achieving the Agile goals; but maybe a team of very fast-typing horrible coders could do the same 🙂
p.s. I have really enjoyed your blog and am _glad_ I didn’t make it to Agile2010 – because that means I didn’t accidentally miss buying you a drink. I at least owe you that much for this blog. Are you going to be at SCNA 2010?
Hi Mark,
Thanks for taking the time to write! Really appreciate it. Unfortunately I won’t be at SCNA 2010 – the cost is an issue, but I’m also best man at a wedding on the Sunday, so could be a bit tricky 🙂
I plan on making it to more conferences in the US in future, so hopefully catch up another time. Or if you’re ever in the UK give me a shout 🙂
I think its a really interesting point you make – in a 90 minute session you can’t really learn something new to any depth, but its a great opportunity to discuss ideas. In my mind, that’s what conferences are great at – free exchange of ideas. I found the most valuable sessions were those where we discussed personal experiences and views, rather than just sat listening to the presenter.
Technical talks often end up “eyes forward” rather than interactive, and that’s what I’d have loved to have seen more of on the technical track at agile 2010: some more discussion-oriented sessions – perhaps along controversial topics. Let developers share ideas and discuss experiences.
I must admit to an embarrassing thing: i had a case of mistaken blog-dentity. I thought this was a different blog when i wrote that p.s.
That being said – i am now going to be reading your blog – it looks good… and the offer of the drink still stands – it would be unconscionably rude to take that back.
I think as you’ve come into Agile recently, you may not be aware that it’s short for “Agile Software Development”.
Agile with a capital “A” started with a fairly strong emphasis on the need to balance programming disciplines with management techniques and people skills. The programming discipline is still the hardest part to master, taking years and years (and years), which is why so many teams have opted to focus on the management and people skills, because they’re easier to learn and someone who spends two days getting a certificate can earn as much or more as someone who devotes a decade to hining their craft.
The upshot of that is that many teams (indeed, most) end up unable to respond to change as their code gets worse and worse. Clean code is a vital ingredient in agility, but we’ve badly overlooked its importance while we get all in a lather about Scrum and Kanban and so on.
Software craftsmanship is an attempt to redress the balance, but the feedback I’ve been hearing from Agile 2010 is that what seems to be happening is the Agile community is in a sort of schism where the programmers are leaning in one direction and the managers and coaches in the other. Both are a problem.
If programmers mess up with requirements and planning and tracking, their development efforts will be compromised. If they mess up the code, their development efforts will be compromised.
Truth be told, it’s a myth that programmers are no good at the management and people side of things. We manage quite happily when we’re given direct access to the customer and the freedom to self-organise. That was kind of the point in the beginning. The many failures I’ve witnessed have had a failure to allow this at their root.
The cynic in me sometimes wonders if the emphasis on management and soft skills (important though they are) isn’t designed to help managers and consultants who don’t write code to stay relevant (and, lately, dominant) within what’s supposed to be a self-organising software development culture.
Hi Jason,
Thanks for your thoughtful reply.
You’re absolutely right about Agile Software Development – but Software Development has always been more than just typing in lines of code. It has to include the customer (somewhere), functional & performance testing, user experience probably get involved and someone has to manage the project and keep track of schedules. There’s nothing saying a properly self-organising team can’t do all this. A developer, wearing his manager hat, can certainly be the one keeping track of schedules, of exploring better ways of interacting with the customer. They might be separate roles, but that doesn’t prevent one person fulfilling multiple roles.
But I think you’re right – there’s an increasing gap between management, which I think agile is now firmly part of; and the craft of software. While developers may get involved in the agile-stuff, the management-stuff – there are too many organisations (my own included), where management and technical are being separated.
But is this just a reflection of people’s natural inclination? There are developers who run projects and developers who just want to get on with coding. In my own experience, for whatever reason, its rare to find developers that *want* to be in a self-organising team, they’d much rather somebody else did all that management crap for them.
This was my point about agile no longer being about developers. Agile has become part of the management side of software development; this is why agile 2010 was so full of agile coaches and consultants, and so few developers.
Software craftsmanship, seems to me, to be much more about (just) developers. I think its sad that more developers aren’t interested in how projects are run, but I think its critical developers master their craft, at least. Even if management is left to managers.
I take your point about clean code being a critical factor to agility, though. Lack of clean code is certainly a millstone around my corporate neck at the minute. We have serious issues with how we run our projects (which is where Agile comes in); but we also have serious issues with technical debt. In my mind, Big-A-Agile is about improving how we run our projects; craftsmanship is about removing (and trying to limit the re-occurrence) of technical debt. We need to fix both to become more (little-a) agile.
I’ve been thinking a lot lately about software craftsmanship (which is how I came across you). I think there’s a real issue now with low standards of craftsmanship – of us all being too willing to pile crap code on top of crap code. The craftsmanship idea, potentially tired though it is, is appropriate: where are the master craftsman training the apprentices? Where is the formally recognised progression through the craft?
There was a great quote, I forget who from now, at Agile 2010 “nobody wants to be a programmer past 30”. This really scares the shit out of me. By age 30 devs are only just getting good at their craft (I know I was, IMHO), if they’re then leaving to become consultants, agile coaches or managers – who’s training the new boys?
I was lucky to work with a couple of brilliant, experienced developers who really taught me the craft. Many people don’t encounter such good teachers. I think that says a lot about the state of software today.
Cheers,
David.
Hi Dave,
no time to write more, so just wanted to say critical and good point you’re making here. I recall working in a locked room with 2 other devoted and skilled developers, with customer test, demo and chat every day, and got my first lean inspiration from that (because the results were pretty awesome). But how apply that when there’s a 100 more people with their different job positions, interests etc…? No time to aim for an answer right now! 🙂
Hi Jonas,
Thanks for your comment! I’d love to hear more / discuss with you when you’ve time.
It seems that small teams are almost by default agile. The whole management-science thing that agile has become seems to be an attempt to re-create that same emergent behaviour in larger teams.
Cheers,
David.