Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Agile project management : managing for success
Crowder J., Friess S., Springer Publishing Company, Incorporated, Cham, Switzerland, 2015. 72 pp. Type: Book (978-3-319090-17-7)
Date Reviewed: Feb 6 2015

What need can a brief (72 pages including index and references) but expensive ($100 hardback, $95 for an electronic version on Amazon) book on agile project management fulfill? The authors say the purpose of the book is “to give managers the tools required to be successful as an agile manager.”

A short introductory chapter summarizes the agile development principles and skills (such as developing trust and facilitating rather than controlling a team) needed to manage agile development. This chapter ends with brief summaries of the other five chapters.

Chapter 2, “The Psychology of Agile Team Leadership,” describes soft skills that an agile manager needs, such as emphasizing the individuals in a team over process or tools. Four high-level skills are deemed essential: effective communication, diplomacy, effective listening, and analytical thinking. It’s not clear why these are not essential for all managers. Next, nine agile team characteristics and constraints that must be defined in order for a team to be successful are listed and discussed, each in its own short section. Some of these are very agile specific, for example, establishing self-organizing concepts and establishing the team’s ability to challenge and question sprints. But others are not agile specific, such as establishing a mentoring, learning, and creative environment, or establishing overall individual and team goals.

Chapter 3, “Understanding the Agile Teams,” covers the dynamics of agile teams and the differences in these dynamics from traditional teams. Once again, most of the alleged differences don’t seem all that specific to agile teams. For instance, there is no rationale or explanation given as to why an agile team would be more culturally, generationally, or gender diverse than a traditional team.

A short chapter 4 purports to discuss agile productivity tools for agile managers, developers, and teams. While the things that such tools for managers should do are listed (manage product and sprint backlog, capture daily Scrum meetings, and so on), there is no discussion of any existing tools or the features these tools should have. The discussion of tools that the agile manager should provide agile developers is similarly limited. Team tools are not described. Most of the chapter is spent on the future of agile productivity tools, mentioning the notion of an electronic engineering notebook as the heart of a collaboration network.

Chapter 5 discusses metrics for managing agile projects, starting with a description of standard non-agile earned value and pointing out some of the difficulties of using earned value with agile development. An agile earned value management system is then introduced. Agile schedule variance (ASV), agile effectiveness (AE), and cumulative agile earned value (CAEV) metrics are defined. No derivation is provided, and only little justification for the definitions. There is no discussion of what possible values are or mean, or any examples either of actual values or of their use in measuring or managing projects. A short discussion of entropy leads to the introduction of two agile entropy measures: team volatility and software defect volatility. Again, the measures are just given with seemingly arbitrary parameters. Volatility of software defects determines if the number of defects is decreasing over each sprint, as the authors claim should be expected. The rationale here is the assertion (without evidence) that as developers become more accustomed to the system under development, and with the teams and team environment, defects will lessen. Even normalizing for complexity, there is no reason to believe this should be true. Again, no actual values or expected range of values for the metrics are given, nor any examples of real-world use. So while the proposed metrics may be useful, the justification for their usefulness is weak at best; their description is inadequate for the reader to know how to put them to use. The last chapter (6) provides a conclusion.

Some 79 references are collected in a final section. On occasion, the references seem strangely disconnected from the text--there are cases where the reference number cited in the text does not match the corresponding numbered entry in the “References” section. The two-page index is too short to be of use.

While there is some good discussion of what an agile manager should do, there is very little on how to go about doing it, how to tell if you are doing it successfully, or what to do if things go wrong. Researchers may find the proposed agile metrics of interest, but managers looking for practical advice on managing agile projects, and especially on tools for doing so, are likely to be disappointed by this book.

Reviewer:  Andrew R. Huber Review #: CR143164 (1505-0385)
Bookmark and Share
  Reviewer Selected
Featured Reviewer
 
 
Software Management (K.6.3 )
 
 
Management (D.2.9 )
 
 
Project And People Management (K.6.1 )
 
Would you recommend this review?
yes
no
Other reviews under "Software Management": Date
The software factory
Johnson J. (ed), QED Information Sciences, Inc., Wellesley, MA, 1991. Type: Book (9780894353482)
Nov 1 1991
New techniques in software project management
Simpson W., John Wiley & Sons, Inc., New York, NY, 1987. Type: Book (9789780471855514)
Oct 1 1988
Mapping situations within a system development project
Lanzara G., Mathiassen L. Information and Management 8(1): 3-20, 1985. Type: Article
Jun 1 1986
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy