Agile and iterative development [Paperback]

Superbly written book that is also very interesting, I particularly enjoyed the chapter on the history of iterative development.

Don't expect a massive amount of detail though, its really just giving you a good overview of agile development and the different processes you can use.

I bought this book as an experienced project manager who has worked historically in organisations espousing either overly-prescriptive or overly-free development methods, wanting to learn a little more about the standard "Agile" practices.

Larman includes lots of good information on why iterative and incremental delivery pays dividends over more "traditional" methods such as the Waterfall, but I found the presentation to be overly fussy and a little too evangelical.

The text is overburdened with references to other publications which may be great if you're fighting an organisational struggle to implement agile methods but if you are looking for practical advice these are of little value. Likewise some of the tables and diagrams liberally sprinkled through the book are probably of little practical benefit to many.

One of the key strengths of the book is that it provides a manager-level overview of the four main agile methods : XP, Scrum, RUP and Evo, whereas many books focus on the nitty gritty of one specific practice.

I'd say it broadly delivers on what I was looking for - a good understanding of what people mean when they bandy the term "Agile" about - my main criticism is that it would be much more readable if it dropped some of the weighty academic argument and concentrated more on the practical.

Its not that the practical advice isn't there - just that the reader can easily get bogged down due to the style of presentation and aspirations to be used as an intellectual sledgehammer to get Agile adopted.

This is an excellent introductory book to the rapidly-growing world of "Agile" software development processes. Although not a new phenomenon, Agile processes have been given a new lease of life after the perceived failure of traditional "Waterfall" process. Waterfall processes are typically characterised by a heavy emphasis on documentation with requirements being frozen before development starts and with the whole project planned upfront.

This approach of mandating that no requirements be allowed leads to inflexibility in the face of business change. In addition, if the project was a large one, delivery of software may occur years after the requirements are signed off. This, coupled with a characteristic lack of stakeholder involvement during development, led to systems being developed that did not truly address the stakeholders' business needs.

Agile processes seek to address these problems by allowing requirements change (in some cases throughout the lifecycle of the project) and that the software is delivered in successive iterations. In addition, the stakeholders are closely involved in the development of the project.

Notably, it is the stakeholders, rather than the developers, that decide which of the requirements is built first. At the end of the iteration, the newly-written software is demonstrated to the stakeholders. Such regular deliveries and close involvement ensures that development does not deviate too far from the stakeholders' requirements.

Larman describes three of the most popular recent software development approaches: Extreme Programming (XP), the Unified Process (UP), Scrum; and an older, less popular one, Evo.

XP is the most well known and notorious of all Agile processes - it was this that kick-started the modern Agile process movement around the year 2000; but Agile processes have been around much longer. XP is characterised by its very short incremental delivery periods (between one and three weeks), emphasis on having a full-time on-site stakeholder and pair programming.

This last aspect has given XP (among developers) its love-it or hate-it reputation. This is where two developers share a one workstation and jointly develop a part of the system; the idea that two people working simultaneously reduces the number defects (bugs) are produced. This can be a big culture change for developers, especially those that are used to working for long periods on their own. Larman gives figures to show that the pair programming approach dramatically reduces the number of defects and how to overcome resistance to the introduction of this practice.

UP is a very popular iterative process framework, particularly its commercial refinement - the Rational Unified Process (RUP). UP/RUP is an extremely comprehensive process framework that was introduced in the late 1990s. It is designed as a framework to be adapted for use on all types of project from the simplest to the most complex.

This very flexibility has led the unwary to use the full framework for all types of project, leading to an over-emphasis on documentation. There is also a widespread belief that the framework is simply a modern restatement of the Waterfall process, bringing all its associated problems. In the book, Larman shows very clearly that by using UP/RUP process correctly, ie as a framework than can be configured differently for different projects, that it can be used in an agile way.

Scrum can be regarded as an Agile project management process rather than a software development process. It is characterised by one-month iterations and daily stand-up meetings where the whole team briefly discuss progress and problems. It does not mandate any particular development style; for example, it is silent on whether pair programming should be used or not. Hence, it is ideally suited as project management "wrapper" to other Agile processes - most usually XP.

Evo is a surprising choice for this book. It is an older process, dating from the 1960s, and has popularity in niche areas such as aircraft manufacture. Larman says that he includes it to show that agile processes are not a new phenomenon. Evo has some interesting features, most notably a good way of defining non-functional requirements and is worth investigating as a potential agile approach for large system development programmes.

As well describing the features, pros and cons of each, Larman gives advice on which process is best used for different project circumstances. This is absolutely the key point; there is no one-size-fits-all process - one has to examine the circumstances surrounding the project and then choose the process accordingly. In this respect, Larman's book is invaluable - he provides guidance on this choice with statistical evidence to support his advice.

He also gives practical advice on circumventing one of the main criticisms of some Agile processes - namely that they do not scale well. For example, Larman describes techniques for using Agile approaches for multiple, geographically dispersed teams. One suggested approach is for the first two iterations to be run with one central team as usual; then this team splits up and "seeds" other teams for subsequent iterations. Larman also discusses how five-team project, located on separate sites across sixteen time zones, was able to work in an agile, iterative manner from the outset.

The book concludes with one of its most useful sections - a series of answers to questions that an attentive reader may have, for example "How to adopt an iterative, Agile process within an existing waterfall process culture?"

Although this book is described as "A Manager's Guide", it is an excellent introduction for business leaders that have had problems with traditional software development processes, that have heard of Agile processes as a possible solution, and would like to find out more. It is also an excellent reference for those who have practised Agile processes and would either like to improve their knowledge or would like to find solid evidence-based support to influence others.