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
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
More of my clients say they want business agility. (That’s a good thing.) Yet, we don’t share a common definition of business agility. My clients mostly discuss their mindset. Mindset might help people, but it’s not sufficient. Instead, let’s consider how to see management’s adaptable and resilient actions. Those actions show that managers change their
Are you frustrated with your board? Maybe three columns don’t offer you enough information. Or maybe you agree with me that teams need to create their own boards. (See the Agile Approaches Offer Strategic Advantage; Agile Tools are Tactics series.) While you’re intrigued by how to create your own board, you have zero money to
I started this series with observations that my clients appear to confuse strategy and tactics. They think agile approaches are tactics and agile tools are part of their strategy. That’s why they want to Buy an agile approach. And that’s why they want to Customize and then standardize on tools. This post is about this