Title: Becoming and Being Agile

Pete looked at his watch which told him that the time was 17: 25. He cursed and waited for the editor and source file to fill his screen. White characters on a light blue background duly appeared and the hunt began. The urgency and stress of the situation precluded any introspective pity - that would be counter productive. He had read how stress can lead to thematic vagabonding or encystment so he relaxed aiming to keep a cool clinical head.

At a young age Pete had learnt to read quietly without speaking the words, most people do. But like a lot of people who find themselves in a state of irritation he muttered the words he read as he typed. He trawled the code inserting trace lines as fast as he could, " insert, head, delete, next...".

Pete was different from the average programmer because he could do more than one thing at once. Reading while simultaneously speaking is well within his abilities so his mind was able to wonder and ponder a little. 'Why am I doing this'? he thought, 'why am I debugging somebody else's code again'? 'And what crap code it is.'

Since joining the company Pete had tried and tried to introduce even the most primitive principles of software engineering. But all efforts seemed to be in vain. At one time he had explained to his colleague Rod the concepts and advantages of software re-use. Rod had smiled and explained that they re-used code all the time. This re-use was then illustrated by liberal examples of similar looking blocks of statements with minor differences. Choosing his most diplomatic hat, Pete had suggested that there were 'even better' ways of re-using code than cut and paste.

Rod was an experienced, intelligent, amiable developer. Above all he wanted to get the job done. Rod's expression was one that Pete took to be one of interest - he wondered if it was that of someone whose mind is elsewhere but who is too polite to end the conversation. Even so he went on "These blocks of code are all very similar, it would be very simple to extract them into a function and supply a parameter to account for the differences."

Rod's expression of apparent interest changed to one of mild disbelief. "When you do you can test it."

If there had been a soap box near by Pete would have mounted faster than an escaping bandit. "Indeed I will but first I will write some automated tests so that the code can be tested and retested in seconds."

Rod's expression be it of interest or disbelief faded in an instance. Now he was listening. And in the manner of many listening programmes his face was completely blank. "With the automated tests I will be able to re-factor the code to remove duplication, make it easier to read, and I will be able to demonstrate exactly what I have tested. Every day!" Rod's expression didn't move, Pete still had his audience. "With the automated tests I will be able to implement a few requirements each day. In each I iteration will be able to show a working system to the business so they can give feedback on whether it is what they want."

Rod's colleague's expression changed to one of realisation. "Oh that's that Extreme Programming rubbish. I've tried that it's no good." All Pete's attempts are resurrecting the conversation were met by a stony wall of 'been there, done that, burnt the t-shirt'.

After several similar abortive attempts he was finally called before the Managing Director and told in no uncertain terms that "this company does NOT do Extreme Programming. I've read the book - it's for hackers". His attempts to explain the relationship between short iterations, feedback and value were dismissed - but he wasn't - dismissals come after three warnings. Pete left the MD's office boiling inside, steam spurting from his ears, and a mist in front of his eyes. How could someone from this company dismiss Extreme Programming as hacking.

Now here he was attempting to debug a classic example of re-use. His thoughts were interrupted as a colleague sped towards the door. It was Norman Moore, normally known as 'that Norman Moore'. "Good night Pete", whispered Norman as he closed the door behind him. Pete was on his feet in a flash and caught Norman as he pressed the lift button.

"Norman!", Pete started, catching his breath. "Weren't you told? Those changes you made for Mega Big Bucks Ltd. still aren't working".

"They worked when I tested them ", Norman retorted. Norman's words tended to slither towards the listener. "Besides I'm going bowling now. Bye." Norman disappeared into the lift.

The delivery to MBB had already been delayed four months. If they didn't get the software to them by tomorrow MBB would cancel the order. That would be the fifth cancellation in as many months. Pete flew down the stairs praying that he would be able to catch Norman and persuade him to stay. As he ran the stairs started to sway beneath his feet. He could feel a warm soft hand stroking his hair.

"Wake Up! Wake Up! You're dreaming again." Pete awoke sweat dripping from his brow. The bed clothes were wrapped tightly around his legs which were still attempting to walk in mid air. He had been dreaming what a nightmare! Pete's nightmare occurred regularly, but he did not mind too much as it helps him to enjoy his new job all the more. Pete had long since given up software engineering and now teaches pilates to rock climbers and professional footballers - at least he was introducing Agility in his own way.

Pete's tail, while (mostly) fictional is a tail that recounts what has happened or could happen to many. It is a tail that relates a situation in which many people, in many companies, in many industries find themselves. A large number of us have seen or been Pete, Rod or Norman. While the tail makes Rod and Norman appear to be villains, this is unlikely to be the case. They are probably intelligent, capable individuals who, given a better environment, would do a whole lot more.

Across the industry there are countless Pete's who want to change their company, improve their development process, become more agile, and make work a whole magnitude more enjoyable. Most of the Pete's struggle in vain, make little or no change, and often devolve into Rod or Norman. So how can you, or I, or Pete make changes? What changes should be made? Faced with a plethora of methodologies, terminologies, and ruthless consultants where should we turn? What should we do?

The answer is not easy, software development is not easy. This article briefly introduces Agile development. In those that follow I hope to provide my thoughts on what it is to be agile, and develop software in an agile way, and what can be done to become (more) agile. I don't claim that I will give you answers. I hope I will say things that you will want to challenge. I will certainly say things that I will disagree with in a year's time - or sooner. My aim is to inform and in doing so I hope I will give you information or incite that will make it easier for you to find answers yourself.

In February 2001 a group of seventeen software pundits got together to discuss the growing field of what used to be called lightweight methods. These people were visionaries who had, between them, created development methodologies such as eXtreme Programming (XP), DSDM, Scrum, Crystal, Lean Thinking, and Adaptive Software Development. They decided to use the term agile to describe this new breed of agile methodologies.

They found that they had a lot in common and agreed on many important aspects of software development. So they decided to go further than just talk. They liked the idea of writing a document that would both capture the common ground and act as a rallying cry to the software industry. Later they formed the Agile Alliance http://www.agilealliance.com as a non-profit organization to act as a centre for furthering agile methodologies.

The document they created is the Manifesto for Agile Software Development. It sets out the values and principles of these agile processes. The values really capture the core of the ideas. The manifesto says what the seventeen stand for and also what they are opposed to or at least value less. Several items were worded to clearly make a distinction between their views and those views of many others in the software industry. Here is the manifesto.

When I first read this my thoughts went from: "Yes, yes, that's it, so right!" to "is that it?" to "what DOES it mean?" This simple statement says masses without saying much - but what does it say? Why is it good? How does it help? In the next article I will give you my (current) thoughts on what the manifesto means and why it is good.