Now you do need don't to anything illegal policies in place, and you might have a [unwritten] moral code of what you can't do. However the purpose is to game the metrics. For all the discussion that follows I'm going to assume we are within these limits.
If the boss wants profit margin as a metric, then you need to figure out how to do things cheaper, and how to get more sales, or higher value sales or some such, and sometimes get something off the books. Note that this last is why smart investors always ask about the bottom line - because the rules of what you can hide from the bottom line are strict enough that the metrics cannot be gamed to your disadvantage. That said off the books is sometimes a useful thing to have - sometimes you know you need to do something hard and so you need to leave an approved way to hide specific things in plain sight.
The problem is most developer metrics are things where gaming the metric isn't good for the company.
This is a lesson more managers need to learn. You don't give engineers a metric to game, they'll run circles around your silly numbers.
My favourite anecdote about this:
I was a consultant for a multinational corp. The Natives had their bonus targets tied to "amount of open bugs at $date".
What did they do? At $date-1 the natives assigned all their open issues to me, a poor lonely consultant - who was outside of the bonus structure.
...and at $date+1 they grabbed their issues back, bonus objectives met :D
I think we just were part of a software factory that is not necessarily bad, it's just a different approach to work. It's much more convenient for a manager to just apply "standard" principles (scrum, 2 weeks, story points, velocity, etc. like a mantra) rather than innovating at this risk of being wrong, difficult, etc.
Too much bureaucracy is not good, maybe that was the purpose of this article. The more you have it, the more difficult it becomes to get out of it, to innovate, etc.
"Metrics" though drive when something might be delivered which triggers marketing spend, hiring requirements and so on. It says "we're working on this now and that next" which drives all kinds of internal storytelling about priorities and cascades down (or up?) into quarterly calls.
How do you do it otherwise without having ipod summers?
Not only that, but if anything else comes up during the "sprint", you're expected to address it while still finishing everything that you (involuntarily) "committed" to during sprint planning.
Thanks, I hate it.
I work in an environment that had no project management tools or methods being used other than emails and I've finally gotten buy in on Kanban and I want to make sure I guide my team properly.
https://www.amazon.com/gp/product/B00A32O00Q/ref=dbs_a_def_r...
Although I think he ended up with something more Scrum-like later at Spotify.
He also has lots of good videos about broader team organization (Tribes etc.) that I found useful for conveying some of these ideas to my non-technical peers.