The New Black

It seems that everywhere I go nowadays people are boasting of their agility. No, these aren’t sudden bursts of enthusiasm for yoga or gymnastics. We’re talking about agile business and, in particular, agile software development but I’ll just stick to calling it Agile. Almost everyone I have met recently has professed to already being Agile.
I have no major problem with this, I’m all in favour of agility and I like to think I’m an Agile person myself. Unfortunately, when I’m not being told that a company is already Agile, I’m often being told that the company has tried Agile and it didn’t work and this rings alarm bells with me.
Several years back there was an excellent school of management known as Total Quality Management (TQM). TQM was based on the teachings of W. Edwards Deming, who is recognised as one the greatest management gurus of all time but unfortunately, it got itself a reputation for failure, which was widely reported in the results of several surveys in the nineteen-nineties. Many organisations had adopted TQM with high expectations, looking for a quick-fix for their problems. When it did not deliver the hoped for results, it was deemed a failure.
Furthermore, many companies had adopted it seeking instant returns. When these short-term improvements did not materialise, many companies became disillusioned with it. This disillusionment and disappointed was reflected in the responses to the surveys.
However, a later, more balanced, survey found that where TQM had been implemented effectively financial performance had improved dramatically and that the reason for failure in other companies was usually poor investment in the implementation coupled with unrealistic expectations.
So when I am confronted with someone who tried it and failed, the question I usually ask is ‘where did you get your Agile training?’ and, surprise surprise, the answers are usually something along the line of; ‘We didn’t do any training, we just started doing it. We read the books, tried it out for a couple of days/weeks/months, it didn’t work and so we went back to our old way of doing things’. Sometimes they try, ‘We sent someone on a course but it didn’t work out.’ And occasionally, ‘We had a guy who’d previously worked in an agile shop and even he couldn’t get it to work here.’
When I fail (a frequent occurrence) at something, I usually look to myself for the reasons why. After all it’s very rare that I ever try anything unique, so if others can do it, I should be able to as well? I have the same two arms, two legs and brain as most people. I usually find that my failures are due to not having a good enough understanding of the concepts or not having the proper tools for the job. It’s very rare that I find that I’ve been doing everything correctly and the failure is not my fault. When my programs don’t compile, I don’t blame the compiler or the language, I blame my lack of preparation and understanding.
A recent of experience of mine concerns one of the most misunderstood of Agile practices, and probably the one that causes most contention, pair programming. On two separate occasions I have been told by developers that they had tried pair programming and found that, although they thought it was great at first, after a little while they and their respective teams had reverted to solo programming.
Through further questioning I discovered that they had had no instruction and had just one day decided (or been told) that sitting side-by-side at one machine was a good thing. They had made no rules about how and when they should pair or who they should pair with. No environmental issues had been considered and by the end of a couple of weeks, their teams had been at each others throats.
Both of these programmers were quite reticent about trying the experience again until after I had explained why their experiments had failed and how that failure could be prevented in future.
The point of this story is that pair programming is a skill. First you have to learn it and then you have to practice it before you become competent in it and even then, you still have to practice constantly or you will lose it. Furthermore, before you can practice it, you need to have the proper tools available and the knowledge of how to use them. You cannot practice playing the piano if you don’t have a piano, even having something that looks like a piano is not good enough – you need to have a real piano and you need to know where to put your fingers.
I play the guitar myself, I often meet people who would also like to play the guitar and I am not above giving an introductory lesson, which is about as far as my level of skill goes. Within half an hour of instruction most people can get some kind of vaguely musical sound out of the instrument. Proud of their prowess, they sometimes ask me if I can teach them more but, after explaining that they will have to buy their own guitar and set aside at least half and hour a day for practice, their enthusiasm usually wanes. Even the ones who do purchase their own instrument will soon give up if they are not constantly encouraged.
Exactly the same thing happens with pair programming and any other new practice. Sure, you can teach yourself, to an extent but it is likely that you will soon reach the limits of your talent and without guidance you will quickly become bored and go back to what you did before.
To continue progressing, or even to maintain your current level of ability, you need proper coaching and you need to practice. Practicing includes assessing your abilities so far, performing exercises that are specifically designed to reinforce the areas that you are weak in and experimenting in new areas. If we carry on with the musical metaphor, we can think of it as the guitarist playing scales and rehearsing regular patterns that occur in guitar music over and over again, starting very slowly and building up speed as her expertise and familiarity increases, until she is proficient.
Starting slowly and learning to increase your speed gradually is very important. Nobody expects even the finest musicians to take a piece of music that they had never seen or heard before and perform it flawlessly the first time they play it. If that were the case, the Royal Philharmonic Orchestra would never need to practice, they could just choose the best musicians and go straight on stage with them. The fact that when they do rehearse, they rehearse as a group and together with their conductor is also significant.
So there’s the thing. Would you expect to be able to give someone a book on playing the piano and expect him to perform a live performance immediately he’d finished reading it? I think that would be classed as an unreasonable request but time after time we ask our employees to do just that. This is exactly what the developers I’d talked to about pair programming had been asked to do. Is it any wonder that they failed?
So if you want to succeed at anything, you need to invest in some training and set aside some time for practice. Sounds simple enough, most companies have a training budget for their developers to be spent on training courses. Whatever you want to learn, it is not normally a problem to book yourself onto a course and have it paid for by your employer.
I’m expecting this year to be the year of the ‘Agile horror story’ and I can foresee Agile being blamed for all manner of ills but, as with the TQM experience, I think history will show that that the cause of failure in most cases was an inability to manage change, rather than the inability of Agile techniques to be adapted to a particular situation.
The transition from a traditional way of working to an Agile way is not an easy one and cannot be taken lightly. Despite the hype from the vendors, agility is not about tools and technology. Agility is about software being developed by teams, working together. This is a major cultural change for most development departments where individuals are praised and rewarded for their individual knowledge and skills. Asking such a group of individuals to suddenly start working as a team is asking them to change ingrained habits and beliefs. Without proper encouragement and guidance this will undoubtedly lead to problems.
Anyway, how do I look today? Pretty good, eh? You are absolutely right, I’m wearing a new outfit. It’s called Agile and it’s the latest fashion thing – if you don’t understand it, you’re probably too old to be in style. Everybody in the know is wearing it, Agile is the new black.