The Product Roadmap is Not the Project Portfolio

I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management. Several potential teams affect each project (or program). Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization. The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on. The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work. When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time. When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time. When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often. All of these teams have dependencies on each other. The project portfolio team optimizes the organization’s output. The product owner value team optimizes the product’s output. The product development team determines how to optimize for features moving across the board. When the features...

Early Release of Agile and Lean Program Management Available

I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public. I find it difficult to release books in progress. The in-progress part challenges my perfection rules. I also know that some of you who want this book will wait until it’s done, or worse, available in paper. However, since this is an agile and lean book, it seems nuts to not release it, even though it is not quite done. If you get the book, please send me comments about what confused you, what you thought was crazy, and anything else. Thanks so much!...

What Model Do Your Estimates Follow?

For years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under. Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.) This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says, “Many projects stay in 90% done for a long time.” What curve do our estimates follow if they don’t follow a Gaussian distribution? Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution. What this distribution says with respect to estimation is this: We are good at estimating small things. We get much worse with our estimation quickly, and for the long tail  (larger and larger chunks of work), we are quite bad. Why? Because creating software is innovation. Building software is about learning. We better our learning as we proceed, assuming we finish features. We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know. You should read Troy’s paper because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long. The question is this: What effect does understanding an estimation model have on our estimates? If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not...

When Should You Move from Iterations to Flow?

I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow. Here are times when you might consider moving from iteration to flow: The Product Owner wants to change the order of features in the iteration for business reasons, and you are already working in one- or two-week iterations. Yes, you have that much change. You feel as if you have a death march agile project. You lurch from one iteration to the next, always cramming too much into an iteration. You could use more teams working on your backlog. You are working on too many projects in one iteration. No one is managing the project portfolio. This came home to me when I was coaching a program manager working on a geographically distributed program in 2009. One of the feature teams was responsible for the database that “fed” all the other feature teams. They had their own features, but the access and what the database could do was centralized in one database team. That team tried to work in iterations. They had small, one- or two-day stories. They did a great job meeting their iteration commitments. And, they always felt as if they were behind. Why? Because they had requests backed up. The rank of the requests into that team changed faster than the iteration duration. When they changed to flow, they were able to respond to requests for the different reports, access, whatever the database needed to do much faster. They were no longer a bottleneck...

Who Removes Your Obstacles?

In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice. In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice. And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.) Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories: Cross-functional problems across several teams or across the organization Problems up the hierarchy in the organization Problems that occur both places, as in over there in another department and higher up in the hierarchy Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem? Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization. Now, I would love...