Product Description

Find out how your company s full project portfolio can benefit from the principles of agility from an expert on agile processes. Agile software development is now more popular than ever, but agility doesn t need to stop there. This guide takes a big-picture look at how portfolio managers and project managers can make use of proven agile development methods to increase organizational efficiency.

It can be difficult for companies to manage multiple development teams and to ensure that they are in line with evolving corporate strategies. Agile project-management methods help you build more flexible processes that invite feedback and collaboration, adapt to change, and gain better project insights. They enable project teams to execute corporate strategy and top-level managers to make sound decisions. This guide delivers practical, real-world strategies for implementing agile methods across your organization. Learn best practices for reassessing your company-wide processes; successfully coordinating multiple software teams without imposing a rigid, top-down structure; developing clear roles and responsibilities; and transitioning to an agile enterprise.

Key Book Benefits:

Delivers practical, real-world guidance on bringing agile software development methods to your entire enterprise Provides specific suggestions for improving processes, developing clear roles, and making decisions Features a survey of popular agile project management methods

Product Details

• Amazon Sales Rank: #149279 in Books
• Published on: 2008-06-30
• Original language: English
• Number of items: 1
• Binding: Paperback
• 240 pages

Features

• ISBN13: 9780735625679
• Condition: NEW
• Notes: Brand New from Publisher. No Remainder Mark.
• Click here to view our Condition Guide and Shipping Prices

About the Author
Jochen (Joe) Krebs is the responsible subject area manager for agile development practices at Bear Stearns in New York City. He spearheads the Agile Project Leadership Network (APLN) and is an organizer of the Agile 2008 conference. He recently published the articles Managing an Agile Portfolio and The Agile Pyramid.

Customer Reviews

Full of misunderstandings with some insights

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.

Accurate Assessment of Conventional Software Processes?
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.

A great C-Level intro to Agile
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.