You may remember that some time ago I wrote a few articles for this magazine on problems my old team had during the planning and implementation of a major project.  I described how the lack of formal planning led to a situation where scope creep and a lack of communication produced quite serious delays; delays that threatened to affect the outcome. 

Luckily, we managed to pull it together at the end, but the support package we had to subsequently provide was quite large. Then, in a subsequent piece I examined some of the possible project management frameworks that could have helped us gain more control. I mentioned at the time that I didn’t think that the waterfall approach was one that could have helped us, and that I thought an adoption of agile methods would have been the best solution. Well, now I’ve found myself at the start of an almost identical project but with a different company; one which embraces the concept of project management and what it can offer. 

The methodology they have adopted is based on the PRINCE2 (Projects in Controlled Environments) system. This system can be seen as having its foundations in the waterfall world whereby a lot of planning and requirements gathering up front leads to a high-level project plan, with most of the costs calculated well ahead of the start of any serious coding. The main stages of a waterfall project can be broken down by starting with the planning section at which the top-level pros and cons are discussed and brought out. This leads into a requirements gathering process followed by a period of business analysis before any real technical work on the design (let alone the code) is started.

The upshot of all this should be a well planned project, with every angle covered and sufficient funding in place to make sure that it all runs smoothly.  However, the downside is that it can be a frustratingly slow process waiting for any workable code to be produced. The majority of early work is taken up with the production of project artefacts required to justify and control the project, but that leaves out any real flexibility in dealing with ‘unforeseens’. PRINCE2, as I have said, is based on this methodology and the adaptation of PRINCE2 developed by my employers has been honed slightly to make it fit with how they want to govern their projects.

In essence, though, the steps of planning, analysis, design, build, testing and implementation are all still there, along with the necessary production of artefacts to control each stage. So, not only am I getting the rare opportunity to learn from previous mistakes, but I’m also getting the chance to practice a methodology I had previously shunned. Or so it would seem. In my eyes, the methodology we have to follow is based on the waterfall system but I want to find out if agile methodology is flexible enough to adapt to PRINCE2.

I have been lucky enough to have been involved at the early planning stage on this project. My previous experience with Customs and Excise was enough to get me brought in at a very early stage, much earlier than the methodology would suggest bringing in a technical designer. However, this was justified by the results that were achieved. The project is working to a very tight deadline, due to changes required by the Customs and Excise department and bringing in a technical designer so early has allowed the framework of the project to be developed in conjunction with the planning. 

In a way, this could be seen as subscribing to one of the main tenets of the Agile Manifesto (http://agilemanifesto.org) which states that individuals and interactions are valued more highly than processes or tools. Within the manifesto, it also states that the highest priority of agile development is to deliver valuable software early, and in a continuous manner. We are told that ‘working software is the primary measure of progress’ and that ‘the best architectures, requirements and designs emerge from self-organising teams’.  What I want to be able to do is to produce a design that allows a team of iSeries developers to continuously present working software, and to put into practise something akin to iterative development.

The main problem we have, though, is the very short time frame in which to actually develop code and test the solution. It might not be possible to produce more than two or three iterations, with increased functionality between the iterations.  Another problem to overcome could well be the attitude of the developers to working in this new fashion. As I mentioned in my previous article, I have been attempting to implement a two-tier approach to some development and the increased amount of time it takes a skilled RPG developer to pick up the new design patterns behind this system can delay a project by a week or two. 

So how do you go about fitting agile methodology into what is essentially a waterfall framework? Agile methods are sometimes characterised as being at the opposite end of the spectrum from ‘plan-driven’ or ‘disciplined’ methodologies. This distinction is misleading as it implies that agile methods are ‘unplanned’ or ‘undisciplined. Well, the project initiation stage is pretty much untouchable in our company. Business leadership is required in every project and is essential to an agile project. In fact, one of the core aims of agile projects is to have continuous access to business expertise. Furthermore, this access isn’t something that can be handled at a management level; it is something that needs to be present for every developer.

Since developers are capable professionals in their own discipline, they should be able to work as equals with other professionals in other disciplines. For too long, the IT department has been seen as nothing more than a service section. In many cases, the finance director of the company will be the head honcho, as businesses struggle to accept that the output of the IT department (or Systems, or even MIS) can produce quantifiable results. The development team is seen as merely fulfilling a function of the business, and you can usually guarantee that their bonuses (if any) will be linked to the company sales and profit, rather than as a measure of what they have achieved. 

How many times have we seen companies downsize their workforce, yet expect the IT department not only to provide solutions to support the downsizing, but also to work within a downsized budget? Truly agile projects should really have the technical and business people on an equal footing in leading the project. Management should still play a role, but it needs to recognise the expertise of the developers.

This then brings us to the technical side. If the project initiation section has been carried out and approved, can you then design an iSeries-based project in an agile manner? The first thing to get right is the team. There is no point trying to impose agile methods on developers who do not want to work in that way. Since agile methods are so fundamentally people-oriented, it is essential that you start with a team that wants to try and work in an agile way. Not only is a reluctant team more difficult to work with, imposing agile methods on reluctant people is fundamentally at odds with the whole notion of agile development. And even if my team does want to work in an agile way, how do I know if my project is suitable for agile methods?

Consider the project. I have a very strict deadline and I know in advance that a lot of testing will be required. Do I try to get the designers to start producing tests while they draw up the technical requirements? Should I get the analysts working in an iterative manner, adding more functionality as the developers produce fully tested software?

I read once that ‘you should pick a project with little business impact to start with. That way, if anything goes wrong then there is less damage. However, an unimportant project often makes a poor test since nobody cares much about the outcome’. This makes sense. The quote then went on ‘…take a project that's a little bit more critical than you are comfortable with’.  However, I think it will all be down to the developers. They are the cornerstone to any agile project, and if they don’t want to work like that, then no matter what I do, when the pitfalls arise, the developers will be more than happy to blame the agile methods. 

Not many RPG projects can be written in an iterative manner, nor will contractors used to programming in RPG be willing to step away from the design patterns that they are used to. It will be a long summer, but by the end of it, I hope to have implemented at least some agile procedures. The concept of self-organising teams is a great one, but I fear the biggest hurdle for me to overcome will be the constraints of the existing methodology. I will let you know how I get on.