Making Sense of Agile Project Management Balancing Control and Agility

Citation

Walker, D.H.T. (2012), "Making Sense of Agile Project Management Balancing Control and Agility", International Journal of Managing Projects in Business, Vol. 5 No. 1, pp. 158-161. https://doi.org/10.1108/17538371211192955

Rethinking Project Management (PM) (Winter and Smith, 2006) has been gaining interest of late with a wider acceptance that PM should be able to cope with a wider variety of project types than the type that Turner and Cochrane (1993) defined as traditional with project goals and methods. We are now seeing more evidence towards a much more rounded set of PM models to apply and to recognise these as better representing the “lived reality” (Hodgson and Cicmil, 2006) of project delivery. One of the newly emerging models of PM comes to us from IT where an alternative to waterfall methodologies such as PRINCE 2 (Office of Government Commerce, 2007; Bentley, 2010) has emerged in the form of agile IT PM (Highsmith, 2004). There has been relatively little written about agile approaches in the PM literature (apart from in some of the IT journals and magazines). Some examples have recently appeared in the PM literature (Conforto and Amaral, 2009; Leybourne, 2009) but they are quite rare. It is tempting to brush off agile as a new fad and one that is evangelically promoted by practitioners with a vested consulting interest. However, there has been sufficient literature in the Rethinking PM mould to justify consideration of an alternative such as agile. It was with this in mind that I decided to read and review Making Sense of Agile Project Management.

I found this to be a well‐written and informative book. Having heard of, and read a little of, agile PM in the context of IT PM I was interested to find out more. By the time I had read this book cover to cover it had provided me with additional understanding and insights into the management of less familiar project types.

The author (Charles G. Cobb) clear makes his pragmatic approach to PM very early on in the text. The book's preface has a neat devise using a table that describes audience characteristics and primary benefits that they may gain from understanding the book's contents. The preface spells out scope and limitations honestly and clearly so that any reader can make a judgement early on whether to invest further time in reading it. The book comprises three separate but linked parts. Part I has five chapters that help readers to understand how to fit agile methodologies into “an overall business strategy that provides the right balance of control and agility for a business”. Part II with chapters 6 to 9 is stated as being designed to help readers “understand how to develop a more agile PM approach […] ”. Part III has two appendices, Appendix A provides an overview of agile development practices and Appendix B provides an overview of agile project delivery frameworks which includes a glossary of terms and suggested additional reading.

I found the content in Part I chapters highly informative. My judgement of a useful book is generally evidenced by how many hand scrawled notes ([…]) obliterate the inside cover and title page. There were quite a few on my copy by the time I started to write this review. Chapter 1 provides an introduction. This chapter describes and explains the “waterfall” or traditional PM approach with the “agile” approach in an engaging and easy‐to‐read way that I found balanced and not at all evangelical. Cobb uses extensive footnotes to reference sources which is a relief. Many practitioner‐oriented books attempt guru status for their authors and do not acknowledge the hard work of others that led to their book. However, this book does tend to rely mostly on a limited source of references, with about five or six main sources being cited and drawn upon extensively. I do believe that this is a fairly new area in general and so there are probably not a lot of reliable published sources to draw upon. Cobb cites the Standish CHAOS 2009 report (p. 10) with 32 per cent of (presumably IT) projects being delivered on time, 44 per cent “challenged” and 24 per cent failed. The CHAOS 2009 report citation does not state that selecting the wrong methodology significantly contributed to this lack of success but it certainly could conceivable be largely explained by applying an inappropriate PM approach. Traditional approaches are inappropriate for high levels of required uncertainty and flexibility because command and control approaches can stifle initiative, flexibility and agility. Chapter 2 goes on to discuss agile values, principles and practices. This draws upon lean manufacturing with a high focus of customer value and benefits. The section on the agile history was interesting and this was well referenced for those want to delve deeper into this area. The section on agile principles is very clear and it ends with a handy table that summarises agile techniques (these are explained in more detail in Part III). Chapter 3 is about becoming more agile and honestly explains the trade offs between productivity gains and losses and limitations depending on the context of how the agile approach is applied. The section on “obstacles to becoming agile” is welcomed and I certainly felt it presented a balanced picture. Chapter 4 presents a case study and this provides useful insights. Chapter 5 provides a summary and action plan which is useful for practitioners and academics that may consider using this as a teaching text.

Part II has a useful couple of pages explaining the relevance and context of the following chapters. It uses an analogy of cooks and chefs to explain the use of knowledge that is normative and basically followed with small deviation from a “menu” and the use of more generalised knowledge that is used for experimenting to build new knowledge. Cobb states that more project managers should be chefs rather than cooks (p. 98). Chapter 6 discusses agile PM in more depth, it compares roles of project managers in both waterfall and agile contexts and also discusses the kinds of skills that are needed of project managers for an agile approach. It goes on to present a few agile models in more detail with good references to more highly specific details of methodologies to be found elsewhere. Chapter 7 then discusses fundamental principles behind software development life cycle (SDLC) models. I found this chapter very valuable. I was struck by some similarities and differences with several relationship‐based project delivery approaches (such as alliancing) that I have been actively researching for several years. The discussion of skills and roles had some similarities with recent work I have undertaken (Walker and Lloyd‐Walker, 2011a,b,c) and I can see parallels between large‐scale infrastructure projects and the IT projects that Cobb is talking about in this book. I suspect that the new product delivery (NPD) and complex systems and services that Davies and Hobday (2005) have undertaken research on also links into some aspects of agile approaches with some shared skill sets that are needed in these environments. Chapter 8 discusses SDLC and in this chapter I saw the content relating to choice of traditional plan‐driven, incremental, iterative plan‐driven through to iterative emergent to adaptive approaches along a traditional to agile continuum as being a valuable addition to the highly quoted Turner and Cochrane (1993) concepts of project types that we see in the PM literature. This is particularly well illustrated in two tables presented on page 183. Chapter 9 provides a well‐written summary and action plan.

Part III has two appendices. Appendix A provides an overview of agile development practices. It explains extreme programming, feature‐driven development, test‐driven development, pair programming code refactoring and continuous integration techniques. In IT these “buzz‐words” are often introduced in papers and articles without explanation which is irritating to those unfamiliar with them. This appendix provides a useful reference to the terms' explanations (there is also a very handy glossary of terms provided from pages 228‐33) so that this book is useful as a reference source. Appendix B explains the agile project delivery frameworks (this is where the glossary is placed). It explains these with clear well‐explained diagrams and models.

In summary, I found this a worthwhile book to read and to keep as a reference. I ordered three copies for RMIT University library. It is a very good book for practitioners but also I feel it to be an excellent one for academics. In many Masters of PM programs there is scant attention given to agile approaches to planning and project delivery and I feel that this book can be used to bridge this gap.