If you haven’t read Resource Efficiency vs. Flow Efficiency, Part 1: Seeing the System, I explain there about optimizing for a given person’s work vs. optimizing for features. Some people (including managers) new to agile have questions about working in flow vs. optimizing for a person. The managers ask: How do I know the work […]
I’ve been working with a number of people who want to work in a more agile way. These nice folks have one stumbling block: resource efficiency vs. flow efficiency. This is partly because of how they see the system of work. If you ever used phases or a waterfall approach, you might have tried to
Commitments or Resilience Ben, a program manager, said, “My management wants a quarterly commitment. They think this will let them commit to customers about features. But, this is a problem for a couple of reasons: we change our minds more often than once every 12 weeks and the managers are talking to other managers, not
I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management. Several potential teams affect each project (or program). Starting at the right side of this image, the project portfolio team decides which projects to do and
I have finished integrating comments from the early review of Agile and Lean Program Management: Scaling Collaboration Across the Organization. I decided that the book was good enough to release to the general public. I find it difficult to release books in progress. The in-progress part challenges my perfection rules. However, since this is an
Creating an Environment of Leadership I bet you have some problems that have been problems for a while. Or, you want to influence other people to change. You need an environment of leadership, because you can’t do it alone. Here are three tips to creating an environment where everyone can lead: Tip #1: Share the
For years, we bought the cone of uncertainty for estimation—that is, our estimates were just as likely to be over as under. Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.) This is a Gaussian (normal) distribution.
I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow. Here are times when you might consider moving from iteration to flow: The Product Owner wants to change the order of features in
In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice. In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice. And, what if you aren’t doing Scrum, or you’re
If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer? If you are