Its role is to promote the practical evaluation of PM approaches by disseminating knowledge of both established and new PM techniques through the experience reports of project managers and others and by promoting discussions between practitioners. So this article is designed to stimulate debate about agile project management - the views are just those of the author. If you don't agree share your views with everyone via PROMSG.
Clearly, as far as agile project management goes there is still business to be done. We have had some great speakers telling us about successful agile projects, such as Paul Craig's talk about the Met Office's Weather on the website, and DI Gary Miles talk about a user's view of agile. Gary described the Metropolitan Police Amberhill project that enabled the rapid dissemination of information about known cases of false identities.
Agile development has become mainstream with central government declaring it to be a key component of their IT strategy. However, the travails of the Universal Credits project have shown that agile is not some magic powder that can be sprinkled on a government project in order to guarantee their success. What are we to make of this?
The problems of deploying agile can be seen as part of a broader problem. Many decision-makers at the top of large UK organisations, both public and private, are woefully ignorant of matters of IT governance. Their lack of understanding of PRINCE2 is an example of this.
Andy Murray, who led the team of writers that produced the PRINCE2 refresh, is a good friend of PROMSG. As he explained at a meeting of PROMSG at the time of the refresh, PRINCE2 is not project management for robots.
Essentially, it describes the information system that needs to be in place for a project to be conducted in an orderly manner. It tells you what decisions have to be taken, but not how those decisions are actually made.
There is no guidance for example on estimating effort / duration or calculating the critical path of a project. However, when organisations have been criticised by auditors for project management, they have regarded the problem as closed if everyone in sight has been sent on a PRINCE2 course. Paul Summers, from Portsmouth City Council, gave PROMSG a lively presentation on what really needs to be done in such situations.
There seems to be similar misunderstandings by organisational decision-makers about agile. If they are uncertain about what it is they are unlikely to implement it. It is worth looking briefly at why agile practices can be successful.
Agile practices intensify the communication between the key players in software development. It does this by reducing the length of communication channels to a minimum.
For example, in conventional IT projects there can be a long time period between someone writing a detailed specification and someone else coding it. This may be because the specifications for the whole application have to be developed before a developer gets anywhere near them. As well as the time loss, if developers have queries they may find it difficult to locate the original specification writers.
Similarly there can be gaps in time between code being developed and it being fully tested. With an agile approach, a user representative can describe part of what is wanted in a simple story. Before this is coded, test cases and expected results can be devised in conjunction with the user. This, in itself, can help clarify the precise requirements.
Once the code is completed, it can be tested using the pre-prepared test cases to ensure that it does what the user expected, and then integration testing takes place on a continuous basis to ensure that it is compatible with other parts of the application. It is typical of agile, that the practice of other developers reviewing the quality of your code, has been transformed into a real-time interaction where two developers sit together at a work station, cross-checking code as it is being typed in.
For agile to work, certain things have to be in place. Knowledgeable and skilled users and developers have to be involved. It helps if there is a single product owner who is the only authority on requirements.
If, for example, a new application merges existing systems of several different users, this will be a challenge to speedy agile implementation. The intense communication at the heart of agile can only really work with relatively small development teams. In my humble opinion, the effective scaling up of agile to really large projects remains a challenge.
This does not mean that scaling up is not possible. From early on in the evolution of software development, methods of dealing with increasing complexity were invented, such as top-down decomposition and modularisation, the breaking down of software into sets of modules where each module would relate to a single function (tight cohesion) and have minimum communication with other modules (loose coupling). This approach suggests that an architectural effort is needed with large, complex system, before agile can be applied.
My own view is that it has been a mistake to regard agile approaches such as Scrum and XP as simply the ideas of incremental and iterative development (IID) which have been around for decades, under a new name. For a start, agile as implemented by XP for example is essentially a set of programming practices - the clue to this is in its name, extreme programming.
IID works at a higher level and promotes the breaking down of projects into increments, effectively a series of small micro-projects, each delivering some benefit to the users. It also advocates iterative development where part of the application can be developed as a series of versions in order to establish, by trial and error, which design best meets the users’ needs.
A rule of thumb is that if the project is complex - and generally complexity and size go together - then a divide-and-rule incremental approach is best. If the problem is uncertainty, for example, about the technical problems to be overcome, then an iterative approach was called for. Geoffrey Darnton, in a presentation to PROMSG about the spiral model, reminded us of the value of early prototypes in reducing risks related to uncertainty.
It could even be the case that a project is both simple and certain. In this case you could have a single increment and a single iteration - and you would end up with a waterfall process.
The key thing is that it is a dangerous thing to assume that the one approach is going to be the best for all projects. Even within the agile school there are different possible approaches. Project planners need to be flexible in choosing the most appropriate approach depending on the risks of the project.
