dmwpepper said
While the basic description of agile portfolio management is useful, I found many of the claims about current software project practices to be based on exagerrated weaknesses of these conventional practices.
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.
Alan Bustamante said
Overall Jochen's book provides a very good introduction to a topic that is rarely addressed in the agile community. Portfolio management has typically been a function that is connected directly to the executive level of an organization because its primary purpose is to link corporate strategy to the projects that are underway within the organization. Many projects will be strategic in nature, but some will not and the goal is to find the balance that makes sense for the organization. It is as much an art as it is a science.
I disagree with the reviewers point on skipping the first 100 pages, because he does not set the expectation that the first section is for readers not familiar with agile software development. As Jochen, clearly states, "The first part of this book is intended for managers who would like to learn more about the benefits and motivations for agile software development." Having worked with many large organizations I can relate to the challenges associated with educating senior and executive level management on the benefits of iterative development. Senior and executive level managers should get a lot of value out of the first section, which covers at a high level, a review of agile software development, how agile ties back to project management, and a justification for the role of agile in an organization. This coverage ends on page 47, not 100. Again, it is high level which should be great for the executive. Any readers wanting a deep dive into the various topics discussed can find plenty of additional supplemental material out there.
The second section introduces Portfolio Management. Here the reader will find the bulk of information on Portfolio Management. No matter what the reader's level of expertise with agile software development, they should walk away with something valuable from this section. I especially liked Chapter 6 on Return on Investment and Chapter 7 on Project Portfolio Management. Chapter 6 will give the reader an idea of how short iterations can quickly build value for the organization and in many cases, return investment dollars much sooner than projects with longer release cycles. Chapter 7 discusses what Jochen calls the "project funnel" for evaluating projects in the pipeline; as well as, the bubble diagram, which readers who are familiar with IBM's Rational Portfolio Manager might recognize. All useful tools when managing the project portfolio
The third section introduces the concept of Portfolio Management using Scrum; as well as, how agile software development impacts the Project Management Organization (PMO). I think the Portfolio Management using Scrum concept is a nice attempt at tying Portfolio Management back to a familiar and popular agile framework such as Scrum. One reviewer pointed out that "It made me doubt the author has actually done this". I think the reviewer needs to understand that this is a PROPOSAL. In fact, Jochen even highlights that "These sections present the Scrum process in the light of portfolio management and PROPOSE how Scrum principles can be elevated to the enterprise level." It is meant to get the reader to read with an open mind, think critically about the subject, and to draw their own conclusions based on their experience and the needs of their organization. Personally, I thought this was a bold step because, as I said earlier in the review, this topic is rarely discussed in the agile world. It leaves Jochen open to a lot of criticism (as it is often very easy to criticize).
I do agree with one of the reviewers that the editing on the book could have been better, on various accounts. However, understanding that this is a first printing, I can be a little more lenient as these types of things usually get weeded out with subsequent printings. That said, the content is good and I would highly recommend this book to anyone looking to understand how agile practices will help them get more bang for their buck from their organization's IT project portfolio.
Stewart Whitman said
As an IT leader in a large financial services firm I appreciated Mr. Krebs' bringing an introduction to Agile to someone with little or no background on the subject.
The book is very approachable and is built for senior managers with very little time (or need) to invest in detailed understanding of Agile.
This book has given me the basis I need to understand where I need to take my organization over the next three years - chucking the old, outdated, mainframe version of software development to a methodology that can meet my business partners need to be more flexible.
I highly recommend this for any IT leader who sees the needs to build a more responsive software development organization.
Bas Vodde said
I was looking forward to this book! An important hole in the current agile literature and a book only on this subject. Finally... but ... I'm extremely disappointed.
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.
Comments