The Agile Manifesto

I only came across the agile manifesto long after I had been applying it to IT in my working life, and I still wholeheartedly agree with its concepts:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It was one of the reasons why I started to get involved in web page development after I had joined the PEGS team in Llanwern: no-one supplied the production people with the information they wanted to have at their finger tips, and could provide them with this information at the speed of development that matched their needs. All the official IT had been outsourced to Cap Gemini a few years earlier, and they mostly dealt with mainframe screens. Not only did it cost you an arm and a leg, but it took months to get requests through the system, and after sitting in the queue for a further few months then got dealt with in a leisurely fashion.

Presumably that’s why Process Control started to have their SQL and web servers, but even then, their speed amounted to development times of weeks to months rather than days to weeks. Fortunately the fledgling PEGS team in its short existence became heavily involved in using mill computer data and extracting mainframe data into SQL, and that’s where I made my first steps into IT land.

From quite early on I made it a principle that the customer could never walk away from the work they had requested. After all, I might have known the IT side of things, but they had the in-depth knowledge of the systems they wanted developing. Of course it helped that I was also a metallurgist and had sufficient process knowledge to think along with them and try myself in their shoes, but in the end I made the development cycle of one where the customer always had to be on hand to make sure that was being built matched their expectations.

To be sure, documentation was one of my weaker points, although at a later stage I tended to produce user guides and expert guides in the wiki, where the user could always the necessary detail to hand over the knowledge to other users. It also helped that for most of the time, I acted as a development team of one, creating the databases, the means of filling those databases as well as the web pages to display and modify the content. Only in my last 6 months in Port Talbot, when I was bringing Theo Vardakis up to speed with my way of working did I have to deal with making sure that we didn’t get in each other’s way, and that what was developed by one person could also be maintained by the other.

I think the most important thing that I tried to instill in him was to make sure you fully understood the customer’s requirements before you started on your development, otherwise you could spend several days producing something that was of no use to man or beast. Presumably this comes in the end when you start becoming used to your environment and the people you’re dealing with, but there’s no better school than trying to do things and learning from trial-and-error.


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