The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there. If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
As I work with more clients on their programs, I see that what might work for a product owner for a team does not work for a program. In a program, if the product owner is shortsighted, does not take advantage of agile/lean for updates, and does not have small features, the program loses momentum.
Agile product leaders (product managers, product owners, and business analysts) all have one goal: How do I support the team in their quest to deliver better and faster? Product leaders do this by helping the team plan with minimums, and continually replan. These two workshops help you do that. I offer two versions: for teams,
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. However, since this is an
Every time I work with a client or teach a workshop, people want more ways to visualize their project portfolios. Here are some ideas: Here is a kanban view of the project portfolio with a backlog: And a kanban view of the project portfolio with an “Unstaffed Work”
Update: I titled it Predicting the Unpredictable. I have finished the content for Essays on Estimation. But, I need a new title. The book is more than loosely coupled essays. It reads like a real book, with progression and everything. I have a number of ideas. They are (in no particular order): Predicting the Unpredictable:
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.
If you saw Large Program? Release More Often, you might have noted that I said, You want to release all the time inside your building. You need the feedback, to watch the product grow. Some of my clients have said, “But my customers don’t want the software that often.” That might be true. You may
I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month. Yes, have a real, honest-to-goodness release once a month. I bet that for some of you, this is counter-intuitive.
Way back when I was a developer, my professors taught me structured design and design by contract. Those were supposed to be the silver bullets for programming. You see, if you specified things enough, and structured things enough, everything would all work out. I thought I was the only idiot that structure and specification didn’t