[lucisferre]

Agile stuff like this just reeks of micro-management to me. To add insult to injury I recall one presenter at an Agile conference a few years ago explain how they added a "delta" value to their velocity so they could also report on the rate of change of their rate of change... Funnily enough they stopped short of just calling it "acceleration". Ugh though.

I have yet to see this type of process and measurement add value or productivity to a project. But perhaps that's just my experience.

[kabdib]

Yeah. My old group at Microsoft started doing "agile" and it just turned into a micromanagement field day, with PMs and middle management in meetings examining charts and calling people on the carpet for missing their estimates.

Look, they're estimates . . . often made by other people than the ones doing the work.

(Oh, and having the build break for two or three weeks running didn't help the "estimates" very much. A culture of build breaking just rewards the people who are less careful than others).

I finally got the PM on our project to call our scrum meetings "status meetings" instead, because that's exactly what they were. Status for rollup into the Great Burndown Chart.

Over two years out of that garbage and I'm still bitter.

When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.

[dragonwriter]

> When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.

Agile means doing it your own way. It means customizing what works for the team and the particular tasks.

Scrum is a fixed methodology with a rulebook.

(A lot of time "Agile" gets used to mean "Scrum" but the two aren't the same, or even the same kind of thing, though the Scrum Book is an often not-unreasonable starting point for an agile organization.)

[alphard]

> When you hear the words "Yup, we do Agile, but we have our own take on it," run away, because it's going to suck hard.

Every team/company has their own take on Agile, copying what other successful teams do verbatim doesn't necessarily work. There are objectively many wrong ways to do Agile (your above example being one) but not any single "correct" way.

[sunir]

No doubt. So, what does work?

Have you been on a team that has added productivity? Note that most teams get more done by adding labour, but that is not increasing productivity. Rather, getting more or better output per labour hour.

Then, how did you know where to focus effort to improve? And that you've increased productivity? Were the teams relying on improving tools, improving practice, and in what mix?

[themgt]

The basic problem is, there are good ways to run teams and bad ways to run teams, but the good ways in general are organic, contextual, intersubjective. It's hard to distill down to bullet points, much less a damn chart.

The most productive teams are the ones that focus on good people doing good honest work, being fairly rewarded, having a meaningful separation/delegation of responsibility/authority, communication, a knowledge of when to gather data and optimize against it and when not to, etc.

So, any time you try to distill team productivity on this cooperative creative endeavor into some number that you're going to put on a chart and give people shit about, you've already lost. If you don't already have a sense of how productive your team is and what the obstacles to increasing that are, chances are you're just a suit and you need to have someone else to run the team.