Daniel Vacanti and Prateek Singh graciously invited* me to be on an episode of Drunk Agile: Episode 37 Johanna Rothman Part Deux More Bigger Aging. (*Invited is their term. I sent them an email, politely demanding they discuss aging. Is it possible to politely demand? I tried. Only they can tell you if I was […]
I’m struggling to write several posts and I realized I need to define my terms. I keep seeing managers confuse the strategic and tactical. That leads to large and unchangeable roadmaps and a lot of emphasis on predictability. I don’t know how to offer the level of predictability they want for large and unchanging work.
When I think about agile approaches to work, I think about how fast we can change and the cost of those changes. We can change the next decisions about the work because we finish the current work and release it. Multiple deliverables allow us to change what we do and what we plan next. That’s
I’ve been working with teams that feel a ton of pressure. On top of the pressure, a senior manager says these words: “Failure is not an option.” When managers say that, they ignore all the possibilities for success. They put their heads down, ignoring ways to manage risk. When managers don’t collaborate to manage risk, we
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
What Happened to the Beautiful Plans? (They Became Experiments) Tim, a senior manager, loved seeing plans for work and roadmaps. Then, the organization decided to Embrace, Not Manage Change. Tim wasn’t sure how to track the work. This image helps me frame the need for an agile approach. (See the blog series: Where I Think “Agile” is
I’ve been working at the intersection of the project portfolio and the product roadmaps. (You can tell because of the various posts about information persistence.) Here’s what I find when I work with my clients: They have years worth of projects in the project portfolio. They have years worth of ideas in various states of description in
Too many teams have overloaded Product Owners. The teams and PO have trouble connecting the organization’s strategy to what the teams deliver. The teams, PO, management, all think they need big planning. Too often, the POs don’t do small-enough replanning. They’re not living the principles of the agile manifesto. That insufficient collaboration means the PO
I started this series with the question: If we have teams for all other aspects of an agile approach, why wouldn’t we want the product owner to also work as part of a team? Could a team reduce the feedback loop durations? In Phase Gate or Other Serial Approaches… When projects use a phase gate
Summary: Too often, customers have a “fake certainty” about the problems they want to solve. They might not have defined the real problem, but they have frequently defined the solution anyway. The risk is that we might build the wrong thing. When the product owner works with the customers to define the problem, then works