Once upon a time, a long, long time ago, there was an IT manager who lived in an ivory tower. Well, to be fair, they didn’t live in an ivory tower. They probably had a four-bedroom detached house somewhere nice, and had a new car in the driveway every few years. The neighbours would know that they ‘worked in IT’, and would often ask if they could look at fixing the computers that young Johnny and Katy had messed up when they downloaded lots of free software off the internet.

When they weren’t constantly helping out their neighbours, the IT manager would go into work every day, trying to carry out the business tasks that they had responsibility for, and to manage and motivate their workforce. They would make decisions on the application architecture that was required, trying to second-guess future developments. They would try and mentor their staff, to teach them and make them feel part of a team. They would have to work long hours as the projects they were leading came to implementation, and they could relax by going home to fix the man-from-two-doors-down’s Apple Mac that didn’t really have anything wrong with it because it was a Mac!

Most of the IT managers I have worked for have begun at the bottom, as a developer or operator, and through hard work, moving jobs and a bit of good fortune they’ve reached the top the ladder. System i departments are notorious for this kind of slow progression. The sheer reliability of the box, added to the fact that the applications are so often legacy apps, with no documentation, and so bespoke that implementing SOA is the only way for the business to survive, means that only through many years of coding can anyone rise to the top. Dead men’s shoes are the route you have to take.

There are many advantages to having a long apprenticeship such as this. You know the systems inside out. You have a good idea of the business politics. And people can respect an internal promotion, as there is less risk of major change. It takes a brave IT manager to push the business down the path of change. However, change is the one thing that will keep them in their job; or rather, how they manage that change is what will keep them in a job.

By its very nature, an IT department has two roles. Their main role is to support the business in its day-to-day affairs. The menu options have to work; invoices and sales have to be recorded. Goods and services have to be supplied, and the staff must get paid. This is the key to how the company makes money.  But with technology moving so rapidly, significant benefits are available to the companies who can best adapt. Cheap disk space provides the possibility of using storage area networks, which in turn can provide the basis for data warehousing and the undoubted benefits which it can bring.

Architectures, such as service-oriented architecture (SOA), are becoming more widespread, and standards are being developed to allow legacy and new systems to be linked together. New tools are on the market which provide better user interfaces; no longer is the traditional green-on-black screen the only way to present information. Introducing and managing change is fast becoming the key role of an IT department, and how a business sees its IT service could well be the key to its success. If you look at project management as being the manner in which change can be introduced, then it is clear that how a business handles project management defines its success.

Agile methods

Regular readers of my musings may remember some of my previous articles on project management and, more specifically, the most recent article in the series, where I wanted to investigate the use of agile methods while working in a supposedly non-agile framework. The framework we had to fit into was the typical waterfall-type, whereby after carrying out an initial planning phase, an analysis phase led into a design phase, which led into a build phase, a system test phase and a user acceptance phase. The task was to see what agile methods could be introduced during a tight project, how they’d fit into the existing procedures and what benefit could be achieved.

The planning phase allowed us to pull together a high-level picture of what we wanted to achieve. Based on that high-level view, we could then begin to resource the tasks we had identified, introduce the project to the business and get deeper into the design. All the while, I was trying to identify what I knew about agile programming methods, and how I could bring them about.

In reality, once the contract developers and designers were brought on board, there was barely any time to decide how ‘best’ to do something. I’ve mentioned already that there was an established project management framework put in place by the business. The designs had to be documented and presented in a peer-group review session. Our designs were quite simple, but involved a little bit of new development in Java which, although it wasn’t quite a first in the business, was enough of a new step to be seen to be a challenge.

We knew already that the normal method of rolling out support changes wasn’t capable of coping with the implementation we would need to perform; however, part of the framework was an implementation review where we had to list exactly how we would implement our project. So much for bringing in iterative development then. To be fair, it must be asked: ‘why try to fix something if it isn’t broken?’.

 
The project management methodologies are there for a reason, and they work. RPG programs aren’t suitable for iterative development, and the Java screens we were providing were to sit on top of an RPG service layer, so the only functionality they would offer was to display a list of information.

However, agile methodologies aren’t just about providing iterative code. Four sentences say it all (taken from the Manifesto For Agile Development at http://agilemanifesto.org):

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

That is not to say that there is no value in the right-hand items. Of course, there is value in comprehensive documentation. However, there is no value in the documentation if there is no working software to go with it. What use is a Haynes manual for a Ford Focus if you have a Suzuki motorcycle? The key thing we managed to do on the project was to build a team of people who were motivated, interested and who were self-organised.

Yes, the majority of the team was contract resource. It could be expected that on a normal project there would be a limited amount of contract resource, but they would only be there to pick up the development that couldn’t be carried out by the permanent resource. If your project is staffed by contract resource, what happens to all the business knowledge? Does it disappear as soon as the contracts finish? Not if you can build in some kind of support handover, or have some of the permanent staff acting in a consultant manner.

We have hopefully managed to provide sufficient documentation to allow our permanent Java developers to pick up the code and support it. Our other contract designers and developers were more than happy to pick up roles that lay outside their remit. As contract staff, they were used to working from a set of documents that told them exactly what to do and how to do it (if they were lucky).

We tried to treat them with a bit more responsibility. We sat them in one specific area where we could build team spirit, and we tried to allow them to bring other skills to the table. These were people with far more experience in the world of IT than I had, so when opportunities (if you can call losing your lead tester an opportunity) arose, the contractors stepped up to the mark and made sure that the team wasn’t let down.
That isn’t to say that there was only contract resource on the team. Our team of business analysts were there to provide the essential business link that any agile project must have. There must be regular communication between the business and the project, in order to keep the focus on the satisfaction of the customers (or business’) needs.

We had four main customers. Her Majesty’s Revenue and Customs was the main one. They were the ones who had carried out the audit that drove the piece of work. The changes then impacted our freight forwarders, the imports department and the suppliers of our duty management package. Only one of these ‘customers’ was an internal one – we, the technical team, relied on the project manager and the business analysts to keep these customers informed on a
regular basis, and also to arrange meetings when necessary.

However, it must be made clear that just because the customer has a request, one should not expect the technical team to be led by this. The technical team are responsible for providing the best design possible, and they are the ones who should design in the changes. Just because a customer has a certain level of technical knowledge, it must be made clear that the final product will result from communication with the technical team, and the ‘throwing dummies from prams’ approach that may be found in some businesses isn’t really classed as an agile method. I’d just like to make it very clear that our project never reached that stage.

We are now entering the user acceptance phase of the project, and we’re hoping to begin some form of implementation in the next few weeks. The main thing I’ve learnt over the past few months is that the agile development manifesto principles are meant to engender communication. Nearly every one of these principles can be tied back to having a good communication structure.

Good design needs simplicity; simplicity lends itself to good communication. No matter what project management methodology you profess to follow, whether it be waterfall or agile, the level of communication between the interested parties can usually measure the success of your project. That’s not to say that if you have good communication, you are guaranteed a successful result, but it’s much more likely.

Agile methods may encompass more than just iterative development and regular code releases, but if you are to truly change anything, then you need to tell people what they have to do and how they are to do it.