[brians]

As a manager, I want to measure leading indicators of success and failure. Absolutely, feedback control based on the real output is important. I must measure that! But I’m always looking for ways to predict that, so I can steer more gently. What’s a leading indicator of a crisis? A late team struggling to make a deadline. What’s a leading indicator of that? Mismatch between estimates and performance. I need to know about bad point estimates because if I don’t fix it—I mean fix the PM’s misalignment—they’re going to push the team into something dangerous.

[quanticle]

The problem is that these "leading indicators of success and failure" aren't. A late team struggling to meet a deadline might be a sign of imminent failure, or it might the team working hard to do something that is genuinely difficult to do.

The core problem with Agile (most forms of software management) is that it massively overweights "first mover" advantage. I keep hearing, as a justification of agile, that software needs to be delivered quickly so that the company can go to market first, and gain marketshare while its competitors are still floundering. But, in practice, that's hardly ever true. I can't name a single product that succeeded solely because it was on the market first. I can name many products that were first to market and failed because they were clunky and difficult to use.

Heck, Apple's entire business model consists of being second to market with a product that is more polished and easier to use than its competition.

Yes, if a developer or team is well and truly stuck (as in spinning their wheels on the same problem, week after week), that's a problem. But you don't need Agile to tell you that. A simple weekly status meeting with incremental demos is sufficient. The only thing Agile does is create a bunch of graphs that allow management to comfort themselves with "story points" and "velocity" so that they don't have to confront the hard reality that they have no idea what it is they want to build.

[iovrthoughtthis]

What about maintaining an environment where the team felt safe to communicate to the pm that there was something wrong?

And for the pm to feel safe enough to communicate to you something is wrong.

This feels like a Taylorism. Knowledge work isn’t factory work.

I totally understand keeping tabs on delivery speed to enable the team to benchmark themselves but the act of identifying a problem from that (if there is one) should be the teams responsibility imo.

As a manager, my job is to enable other people to do their job the best they can.