> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
Story time...
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
Story time...
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.