I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what […]
I posted my slides for my Agile 2014 talk, Agile Projects, Program & Portfolio Management: No Air Quotes Required on Slideshare. It’s a bootcamp talk, so the majority of the talk is making sure that people understand the basics about projects. Walk before you run. That part. However, you can take projects and “scale” them
I sent a Pragmatic Manager email last week, How to Avoid Three Big Estimation Traps. If you subscribed, you’d have seen it already. (That was a not-so-subtle hint to subscribe 🙂 If you’re not sure of the value of being on yet-another-email list, browse the back issues. You can see I’m consistent. Not about the
How to Avoid Three Big Estimation Traps I bet you need to estimate how large your project or program will be, at the gross level: “It’s bigger than a breadbasket. It’s smaller than a person on the moon.” More likely, “It’s about x people for about y months with this percentage confidence.” Or, you use
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum. I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they
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.
This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the program management book, I will talk more specifically about change and what to do. This post is the highlights.) Project
If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want
What do you do for geographically distributed teams, if you want to move to agile? First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious. I might take the same actions, but for different different reasons. In either case, the team needs to
The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange