[luka-birsa]

I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process.

I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead?

I'm a CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?

If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.

[fileoffset]

Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.

Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.

Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...

[luka-birsa]

You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.

My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.

I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.

I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.