The discussion to now: Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability When you move from resource efficiency (experts and handoffs from expert to expert) […]
This is the next in a series of posts about resource efficiency vs. flow efficiency… Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability: Accountable to the project for finishing their own work Accountable to their team for participating fully by doing their
Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System explains resource efficiency and flow efficiency. Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People explains why flow efficiency helps you get features done faster. Here, in part 3, I’ll address the performance management question. New-to-agile (and some experienced) managers ask, “How can I manage
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 see people measure all kinds of things in projects. Too often, they are single-point or single-dimension measurements. Those measurements don’t provide you with a good idea about the health of your project. They might be a start. However, they are insufficient. Imagine you, like me, would like to lose some weight. You weigh yourself
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features
A cargo cult occurs when people adopt rituals expecting some good behavior to occur. They really don’t know why they are doing these rituals and don’t understand the reasons behind them, yet they keep doing the rituals expecting great results. In this article, I’ll give two contrasting examples that I’m familiar with: Project A talks