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
I see too many teams feel frustrated because their managers say the work takes “too long.” (The team feedback loop is the inside of the onion for how agile the organization can be. See Multiple Short Feedback Loops Support Innovation.) The longer the work takes, the more pressure managers exert on the team and the
Many agile teams and product leaders assume they can make many product decisions on their own. They do have some constraints, such as “this kind of customer” and “these kinds of problems.” However, as the teams work together and explore the product, they assume they can decide on the designs and architecture. Product leaders assume
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
My clients all have too much work to do. So they ask the product or project leaders to write a business case for each effort. The clients claim this information helps them decide which work to do and not do. However, everyone knows each business case is at least partially fiction. That’s because the writer
Do your senior leaders want more predictability about when your team can finish its work? Perfect prediction is impossible, and sometimes, even reasonable prediction is quite difficult (with apologies to Yogi Berra). However, agile teams have one specific “tool” to create better predictability: right-sizing their stories. When a team right-sizes their work, they can create