The AgileNorth group helped run an XP Game last night in Manchester. The event was organised jointly by ourselves and the good folks at Exoftware, on behalf of the Agile Alliance Europe programme. There were twenty-nine of us, including our facilitator David Putnam of Exoftware, and we all had great fun. We worked in 4 groups, coached by me, Brian Hanly of Exoftware, Murray Tait of Deltapoint and Stephen Hutchinson of Accenture. My group finished last!
Now, if I can find a couple of coaches, I’d love to try to run the game at my current place of work. Might as well be hung for a sheep as for a lamb…
I’m really excited: I’ve heard a great deal of praise for the XP Game, and now our local agile group is going to run one! It’s in Manchester on October 13th – see http://www.agileallianceeurope.org/uk_home/ManInvite for details.
The more I think about it, the more convinced I become that selling agile at all is a mistake. Certainly as a coach/manager, what interests me most is the ‘process’ side of things, and agile is always an interesting and rewarding approach for both me and (I hope) the software team. But what interests my bosses is more often the business value delivered to the user base.
I’ve never been someone who believed that it works to simply plonk a methodology onto a team straight from a book. Every team is different, and every business is different; enforcing conformance to some pre-determined monolith is likely to bring out as many minuses as plusses. And I believe that’s true of the agile methods just as much as it is of the heavyweight ones. What’s more, the successes I’ve been associated with have all been due entirely to having the team grow their own processes – gradually, incrementally making the changes required by the current situation. Only when the current way of working is shown to fall short in some respect does the team call a review and work out a different approach. There is never any change simply for the sake of it.
Of course the agile movement directs and informs my thinking, and hence my coaching and management styles. And all of the teams I’ve coached have become increasingly agile over time, without any of them ever consciously adopting a ‘book’ method. The stakeholders get to learn that iterative and incremental delivery is better for everyone, that feedback loops must be short, that quality helps the team go faster, etc etc. But most will never hear the words ‘agile’, ‘SCRUM’ or ‘extreme’.
In the future though, I do expect I’ll be using the word ‘lean’ a lot…
There’s been a thread recently on Clarke Ching‘s SellingAgile list about selling agile to developers. My approach has always been to ‘just do it’ and lead by example. Here’s the story I told on the list:
I too was faced with this problem about four years ago. I believed the book, but I had never tried it for real, so why would anyone else believe me? So I just started to follow the advice in the XP white book on my ‘own’ subsystem (yes, it was that kind of shop). After a couple of months I started to get the hang of things, and ‘my’ software started to be much better. At that point other developers began to notice things like the hourly build and the test suite (and the lack of bugs ;-). Soon most of them wanted to try it, and we were off down the agile road.
(As it happens, potential management objections never materialised, because I was soon promoted to lead that project. I’d like to think that was because of my natural charm and leadership abilities, but more likely it had something to do with working software delivered on time and with fewer defects…)
I had an experience a few months ago that yet again raised the question of what kind of skills are required to make XP work. I was trying to get a team to adopt TDD, and was having very little success. The reason, it turned out, was that the existing code hadn’t been written TDD. Anyone trying to add a new feature incurred a huge time penalty from trying to get to the point of being able to write simple unit tests.
So I stepped back from TDD and tried to get the team to only produce well-factored code from now on. Another failure, and this time the legacy code was only partly to blame. It turned out that only two of the fifteen people on the team really understood what well-designed object-oriented code looks like. The rest wrote working algorithmic code, and were completely blind to the duplications and strong couplings they had created. For lots of reasons, including timezone differences in some cases, it was impractical to pair with everyone to help them towards an understanding of ‘simple’ code. So I did a few public worked examples via NetMeeting, and still had almost no impact on the code being produced. I guess that refactoring is a design skill, and that it has to be taught, because most programmers don’t learn to appreciate ‘good’ code in university.
Many thanks to Bill Caputo for bringing this article about metaphors into my range-finder! Like Bill, I use metaphors a great deal in everyday conversation, and yet I hardly ever set up a system metaphor as recommended in XP. Which is doubly odd, because I’ve read a lot of George Lakoff‘s work and find myself completely captivated by his thinking. The idea that we develop our higher thinking by piling up metaphors on top of the actions we perform as babies is enormously appealing, and I hope he finds the time to demonstrate the effect in most areas of our cognitive lives.
So why is XP’s SystemMetaphor so misunderstood and under-used? My personal view links back to a topic we discussed at length at a recent agile nw meeting: that in order to work successfully XP relies on the presence of at least one, and preferably two, extraordinarily talented individuals. Clearly Kent Beck is one of those individuals, and it would seem that SystemMetaphor is one of his preferred cognitive tools. It would also seem to have worked successfully on a number of his projects. But not everyone can (or needs to) think in such a way about systems. My guess therefore is that this is the one case where Kent’s intuition was more personal than he realised – he can make it work, but most other folks can’t…
Many thanks to Lasse for bringing the following quote to light:
All abstract thought is based on metaphors. The question is
not whether you will think metaphorically or not. The question is whether you will become aware of your metaphors and choose them consciously.
— Kent Beck
It seems to me that one of the principal reasons for the apparent rapid rise of agile methods in software development is the romanticized battle between programmers and managers. Spend any time reading any extreme programming discussion group, for example, and eventually the topic of adopting XP in the face of management resistance will crop up. Agile methods, and XP in particular, would appear to be the saviour of the oppressed programmer; finally the evil tyranny of the waterfall and the heavyweight methodology are crumbling in the face of guerilla resistance from programmers who knew they were right all along! Or that’s how it seems to them.
Does the extreme (sic) zealotry of the programmers represent years of pent-up frustration with the situation in which they found themselves? Do they blame management for controlling them, for keeping them strait-jacketed in heavyweight methods for so many years? If that’s the reason, why were such methods of control deemed necessary in the first place? Two words: manufacturing metaphor.
Last night we had another very interesting meeting of the NW agile SIG in Warrington. Much of the debate focussed on whether XP is too brittle, because it only really ‘clicks’ when the team is doing all of the practices with all of the dials turned up to ten. We wondered about dependencies between the practices, and whether any one practice could/should be adopted first, with a few surprises to us all! Rob Jarratt has now posted comprehensive notes of the discussion on our website.
And when I got home, I discovered just how much Donna disliked our gorgeous (I jest) stone barbecue:
She may be only 5 foot 1, but give her a lump hammer…
So that’s gone now – but at least we have a nice pile of cut stones for that ornamental wall around the patio. When we get around to putting in a patio, that is…
It turns out that I’m the new editor of the dmoz category Computers: Programming: Methodologies: Agile! The RSS feed from XPday Benelux has just reminded me that there are also XPdays in Germany and London in November this year, so I’ve just spent an hour or so adding them, and trying to bring a little order and completeness to the : Extreme Programming: Conferences sub-category. If you can think of any relevant conferences I’ve missed, please either suggest them via the link at dmoz, or add a comment to this blog entry, or email them direct to me.