- Paperback: 240 pages
- Publisher: Microsoft Press US; 1 edition (16 July 2008)
- Language: English
- ISBN-10: 0735625670
- ISBN-13: 978-0735625679
- Product Dimensions: 18.8 x 1.5 x 22.9 cm
- Average Customer Review: Be the first to review this item
- Amazon Bestsellers Rank: #8,41,301 in Books (See Top 100 in Books)
Agile Portfolio Management (Best Practices) Paperback – Import, 16 Jul 2008
Customers who bought this item also bought
About the Author
Jochen Krebs is an accomplished agile mentor and instructor, and the founder of an agile coaching and training services company. He spearheads the local chapter of Agile Project Leadership Network (APLN) in New York, speaks at industry conferences and corporate events, and has written numerous articles about agile practices. He is also the coauthor of the IBM RATIONAL UNIFIED PROCESS REFERENCE AND CERTIFICATION GUIDE.
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter mobile phone number.
Most helpful customer reviews on Amazon.com
Part of what defines agility is the ability to embrace change. But many organizations have spent years trying to minimize change, trying instead to refine their approach to the one, true, perfect approach. So learning to embrace change is a huge change itself, and project, business, and technical management that feels very dubious about taking an unknown approach can take great heart from seeing that others have crossed this minefield, have handled the problems already, and are making great steps forward.
This book is not the only volume on agile portfolio management (see Johann Rothman's work too, for instance) but it's a valuable addition to any agilista's shelf.
Jochen Krebs' Agile Portfolio Management consists of 3 parts. Part one is called "Agile for Managers", part two is the things about portfolio management and part three is *other* called organization and environment.
The first part consists of three chapters. The first chapter consists a general motivation for agile development and responding to change. The second chapter is a short introduction to Agile development and the last chapter an introduction to project management. This takes up 1/4th of the book. The explanations are poorly written and full with misunderstandings. To give a concrete example, on page 27 Jochen is suggesting that in Scrum you can not have any other meetings except for the daily Scrum. A recommendation which I've never heard before and I'm pretty sure he didn't actually mean that!
Part two consists of about 125 pages and is the main subject of the book, though it starts with three somewhat introduction chapters called Foundation, Metrics and Return of Investment. These chapters don't show too much experience from the author. The suggestion that TDD and Continuous Integration finds defects early so that one of the main quality metrics is open defect count is absurd and goes directly against advise of great agile literature like "Art of Agile development" or "Sustainable Software Development". It gives the feeling the author simply forgot to learn about agile development before he wrote the book. The explanation of story points was vague, the explanation of Use Case points unnecessary. The talk about return of investment forgot to give actual tools for doing so.
After the first 100 pages, I almost threw away the book and was pretty sure I would rate it 1 start. Though, luckily it started to improve. If you buy this book, I recommend to skip the first 100 pages :)
Chapter 7, 8, and 9 cover three portfolios: Project, resource and asset. The project portfolio covered some good ideas like increasing the portfolio decision frequency, using agile metrics and making other decisions than go/kill. The resource portfolio chapter was poor and doesn't talk much about resource management. The asset portfolio chapter is short but covers some important topics not covered frequently in other places.
Part three just consists of two chapters. The first one uses Scrum to become a portfolio management process. I found the idea interest and absurd. Especially the daily portfolio meeting and the portfolio master seen a sure sign of misapplication. The chapter is speculative, the real story about the real situation is missing. It made me doubt the author has actually done this. The second chapter of part three is a chapter about the PMO. I very strongly disagree with the suggestions from the author, especially making the PMO larger for Agile organizations.
In other words, I only thought that part two was worth my time (and only half of that) thats about 50 pages... Next to this, the writing and editing of the book was poor. Some constructions seem very German and sentences are constructed poorly making me sleepy while reading. I wonder if Microsoft Press did any editing at all or supported the author at all. Quite disappointing.
I would not recommend this book to anyone. It's probably better to read some traditional portfolio management book (e.g. Coopers Portfolio Management for New Products) together with some basic Agile books and especially Mike Cohn Agile Estimating and Planning (which covers much of the ROI and value calculation, but explained better). If you read all of these and want some insights and ideas from this book, just read chapter 7, 8 and 9 and skip the rest.
I still rated this book three stars, which is probably too high. After the first 100 pages, I was sure it would not be higher than 1 star. But some chapters contained some insights and that made me decide to give it 2 stars. I switched to three stars simply because I applaud the attempt. This is a new area, there is no existing material and it is great Jochen took this opportunity and tried to fill a gap. Though, a different book is probably needed.
I believe the author exaggerates the differences between customer expectations and customer requirements. While they can be different, competent systems analysts can capture and document expectations, as well as requirement. The author's view is that traditional requirements analysis, for various reasons cannot be expected to capture customer requirements in a timely and "agile"/adaptable manner. My experience is different.
The author also claims that traditional project management practices contribute to a lack of agility. WBSs, GANT charts and other techniques are inherently inflexible, rigid and labor intensive, in his view. My experience with tools like Microsoft Project is that what-if scenarios and other hypothetical and actual adjustments are easy to create and provide the kind of decision support a project manager needs when requirements change, resources come and go, or schedules tighten unexpectedly.
Having worked on a number of rapid prototyping and quick reaction environments I realize that keeping up with customers that have a fast ops tempo and shifting focus can be a challenge. For that reason, I strongly agree with the author on the value of constant interaction with the customer and stakeholders, continuous builds, on-going testing and integration, teams being given wide latitude to focus on developing solutions and managers focusing on removing impediments. However, the author claims that these and other practices he discusses are unique to an agile development environment.
In my view, agile development represents just one confluence of best practices identified over many years and under different labels, such as rapid prototyping, joint application development, spiral development, Rational Unified Process (RUP), etc. While the author discusses these and other methodologies, I think his comparisons and contrasts with agile development are superficial. RUP, in particular, is not given its due as being an "agile" process and project management framework that can be used on different kinds of software projects.
I'm more of a middle of the road person. I tend to blend the strengths of many different approaches and when I read something that maximizes its strengths while exaggerating the weaknesses of other approaches, I tend to be skeptical. From my own experience with dynamic customer environments, I wonder if the author's description of agile development would lend itself to an EFFICIENT discovery of complex requirements. What's more efficient and agile, trying to code to "vague" requirements and continually coming back to the customer saying, "Is this the rock you wanted?" or holding some JAD sessions, getting with subject matter experts and prototyping aspects of the system that are not clearly understood? I'm not sure the author's description of agile development adds anything new to previous techniques for clarifying vague requirements or discovering unspoken requirements. It just takes a team of analysts, developers and stakeholders willing to work closely together, whether it be in the Elaboration phase of a RUP-based project, the 1st or 2nd iteration phase on a rapid-prototyping project or (get this) even in the requirements analysis phase of a traditional life cycle project.
Also, to me, the notion of "stories", "epics" and "themes" represent unnecessarily relabeled and watered-down versions of more mature UML techniques that model system structure, behavior and human-system and system-to-system interaction. To his credit, the author did spend time discussing the application of use cases which are easily implmented graphically and textually in UML.
While the author does bring together a number of concepts that are useful for running a project, he doesn't make the case that agile development, as a whole, is a major departure from conventional practices, but I like adding some of the "tools" he discussed to my toolbelt.
Look for similar items by category
- Books > Computing, Internet & Digital Media > Programming & Software Development
- Books > Computing, Internet & Digital Media > Software & Business Applications
- Books > Reference
- Books > Textbooks > Computer Science > Programming Languages
- Books > Textbooks > Computer Science > Software Design & Engineering