Most managers I see feel a ton of pressure for delivery. The managers need to “deliver” more projects, products, and features. That pressure rolls down to the teams. Too often, the team hears, “Can you just do a little more?” That often leads to the so-called “quiet quitting” problem. The problem isn’t quiet quitting. The […]
The news is full of this idea of “quiet quitting.” That’s where people do just what the job requires and not more. Well, I have a contrarian view: Why do managers think it’s okay to ask people to do more? What is it about “more” that managers want? In Practical Ways to Lead and Serve
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