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. […]
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
In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.) Managers ask for estimates because they want to
Go Small to Gain Momentum You’ve seen projects that start off great. They zoom along, delivering. And then something happens. They slow to a crawl. Sometimes, they get stuck so badly you decide to stop and declare victory (or defeat) and start all over. What can you do to make sure that doesn’t happen to
In my article, Which “Scrum Master” Are You Hiring?, I suggested you articulate the type of leader you might be hiring. Why? You might not be hiring a “Scrum Master” at all—but you are likely hiring a servant leader. In this article, let’s discuss the kind of qualities, preferences, and non-technical skills you might need
Have you looked at some of the ads for Scrum Masters lately? Some ads include the need for PMPs or they say they will give you a bonus if you complete the project at a certain time or to someone’s satisfaction. Some talk about hiring the team or about managing the customer’s expectations. Some talk
Scale Agile With Small-World Networks Some organizations, when they think of programs (a collection of projects with one business objective), think of many teams, each with Scrum Masters or project managers. That’s one way to scale agile. That’s scaling up. It creates a hierarchy. Hierarchy can slow you down with centralized decision-making, coordination, and communication.
Time for a Decision On a recent flight, I sat next to the VP of Sales for a large multinational company. Their new big product in development needs a new pricing structure that requires agreement across the organization. Can he get a decision? No. He’s conducted conference call after conference call for months. No decision.
One problem when you have a program with agile projects and non-agile projects is how to marry the two parts. The agile projects deliver value every couple of weeks. The non-agile projects? Well, it’s possible they don’t deliver value for months to years. In Managing Programs with Agile and Traditional Projects, I suggested that you
Imagine you are transitioning to agile. You are a program manager with a few agile projects and a traditional project. How do you manage the program? Possible Technical Program with Communities of Practice Above is my drawing of what a technical program team looks like. Sally’s project is actually a small program itself. Sally is