When I posted How to See Your Leading, Lagging, and Reliable Estimation Metrics last week, a colleague suggested I was not quite right. He said that Aging is actually the leading indicator for more reliable data. He is absolutely correct. However, we don’t always see the real problem. The reader who emailed me only saw […]
A reader asked me these questions about reliable estimation metrics: Would you explain leading and lagging indicators? Can I use a burndown chart to see accurate progress? Is that burndown chart useful if the team has not yet finished grooming the work? These are great questions because too many of us think the answers are
I said earlier in this series that no one cares about how “agile” your team is. Or the kind of “agile” your team professess to be. Managers do care about agility: the ability to respond quickly to a changing or changed environment. And that depends on where your team has delays. That’s why value stream
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. In Part 2, I discussed cooperative teams that have working agreements on when to do code review or make other decisions as a team. While those teams exhibit somewhat more agility, cooperative teams are still not collaborative. So
In Part 1, I wrote about what the value stream map looked like for expert-focused “cross-functional” teams. While those teams are cross-functional, they are not collaborative. However, these expertise-focused “teams” are not the only type of non-collaborative agile teams. There are also cooperative teams. Cooperative teams still tend to work sequentially, focused on each person’s
We talk about cross-functional agile “teams” as if they are the norm. That’s what I show in this image: some responsible person creates a ranked backlog that the cross-functional, collaborative team works on. That team delivers increments of value on a regular basis. At some point, the team will demo their work and retrospect on
Maybe your team does have Ready criteria for their backlog. But they look at the backlog item, and they say, “Oh, this is way too big. We have no idea how to start.” That “no idea” often means the work is too large, unclear, or not based on a specific customer with a specific need.
Does your team feel as if they can’t really start when they take an item off the backlog? The team says the item feels too big. Or the team realizes they need someone else from some other team to solve this problem. Worse, the team needs to decompose the item more to make sure they
I’ve been working with several supposedly “agile” teams and their managers. Everyone knows their project is in trouble. And they have no idea what to do about it. The team members say, “We’re on a death march. We have no predictability. Everything takes longer than we think it will.” The managers say, “We have no
I use many apps on my Mac, iPad, and iPhone. There is clearly something in the air because, during the past three weeks, most of them broke. Here’s a partial list: The password manager (on all three devices, with at least 4 failure modes) Two different health-based apps Various kinds of email-based apps What do