I started this series by sharing my status of too much WIP (Work in Progress). My WIP was making me slightly crazed and I explained how I worked to reduce it. In case you’re wondering, here’s my current status: 3 presentations still on the list (I completed 2, including the one I recorded). The online […]
I hate the fact that I let my WIP get this high—and I’m glad I’m working it down. (I wrote why I let my WIP get this high on my other blog in the post, What Would It Take for You to Fail to Success?) My status today: Finished one more presentation and need to
I’m halfway through this week of working through my too-high WIP. So far, I exposed my WIP and talked about how I planned to use continuous flow in Part 1. Part 2 was about cycle time and using Cost of Delay to make easier decisions. Today is about why I don’t use a real backlog
As I said in my Day 1 post, my WIP is too high. Here’s where I stand with my WIP: I completed one presentation, so I have 4 remaining I have some feedback on the book that I need to integrate. I want to address the next 3 chapters, because they’re the platform for the
As with many of you, sometimes my WIP (Work in Progress) is too high. When that occurs, I don’t use a backlog or create iterations. Instead, I use continuous flow. That’s because working in flow allows and creates ease in my development. This week, I want to finish these things: 5 presentations, one of which
A project portfolio manager contacted me via LinkedIn. The question: How can this portfolio team start to manage the project portfolio when the organization has 600 projects? Right now, the portfolio team is supposed to read the status decks for each of those 600, to understand each project’s status. How to start? That’s an impossible
We use product roadmaps to see where we want to go and the options we might take to get there. Yet, so many of our roadmaps offer only a single and certain destination. If we don’t see options, we reduce our innovation decision points—and possibly disappoint our customers. Worse, we create products that don’t fulfill
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,
Acme’s project portfolio team was stuck. Three months ago, they’d funded five experimental projects at $150k each. The portfolio team hoped those projects might offer the organization new customers and revenue streams. Now, the project teams reported several concerns: The technology was more complex than anyone had expected. Instead of the teams’ typical 2-4 days
Dan, a VP, knows he needs more people to get the work done. Suzanne, one of the directors, starts to hire and realizes she has several problems. First, their salary bands are too low—candidates want more money. In addition, the people want to collaborate more than the existing people seem to. She meets with Dan