My goto example of a dysfunctional and bureaucratic organization is an example I saw in a finance …

I have seen this multiple times before. Management chastising good work because some externality of that work shows up on a graph that they have to talk about at some weekly meeting. It doesn't even have to make the graph look bad, just stick out.

I am dealing with this as a Senior Product Manager, explaining to execs, and defending my engineers when they started introducing metrics, and one of the keys was "Planned points delivered". My team gets and triages all the escalated bugs. It's not accurate, not fair, and demoralizing for that team to be "red" because the metrics look like: "Story Points Planned: 30. Planned points delivered: 5." when they delivered bug fixes on what amounted to 20-30 unplanned points. "If they have to do that work, they need to get credit for it, planned or not. You can't have work that is required but counts for nothing in KPIs". The issue of HOW MUCH unplanned work is being required is a separate and valid discussion, but not in the realm of "engineering cadence/velocity".

>No of course not, we doubled our number of tickets and filled in "placeholder" on half of them, and used them as needed then closed everything out at the end of the sprint, where we were congratulated by everyone for our phenomonal estimation. Are you sure this is a negative example? You even have a work around which makes everyone happy. This isn't what a dysfunctional organization looks like.

That is amazing. I worked with a (different?) finance company that did the same thing - every team was judged on their burndown charts. From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.

> Everyone should have been thrilled by this development! Well we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery. Why should they be thrilled that you were running on Kanban but claiming to do otherwise and therefore ruining the burn down charts?

I also work at a large financial institution and have had many similar situations. Fortunately, I'm the one in charge (team lead of sorts) and I have a pretty standard response to such "high level" nonsense: "Your inability to adequately track my team's weekly or monthly performance is not my problem." Every "project" has plans, deliverables, and due dates and those are the ultimate arbiters of a team's performance. Not the weekly/monthly statistics! If we open 10 or 10,000 tickets it makes no difference. It's entirely arbitrary and only carries meaning for the team in question (not upper management). Like some high-level manager/PM is going to be able to make any difference whatsoever on some software development task by watching weekly Jira ticket statistics. Sounds like they're giving themselves busywork to justify their role. Because having fancy charts and statistics at meetings of …

> we had a sprint review where some "Senior Project Manager" That wasn't really affiliated with our project but was some manager higher up was mad that us opening up new tickets mid sprint and closing them was ruining the org level burn down charts and expected delivery. This is giving me flashbacks of a company I worked for (for a very short period of time). For some reason, they decided that planning accuracy was the most important metric for the software organization. This was the headline metric they talked about in executive meetings and it was primarily how the program managers' bonus structure was determined. So everything in the company revolved around planning accuracy. Opening new tickets within a sprint was strongly discouraged. Doing work from the next sprint was heavily discouraged. Trying to take on big projects within a sprint was heavily discouraged, because if you couldn…

I experienced something like this for many years across several of the big five defense contractors and smaller SBIR contractors working for the US DoD and IC. As someone who 20 years ago had a slightly better understanding of how computers and networks actually work than an average developer and was comfortable at the command line in an era when juniors increasingly couldn't leave their IDE without becoming hopelessly lost, as DevOps, SRE, and platform engineering started to become things, my career drifted in that direction. The problem being on teams like that was always the same. You're responsible for developing software products of some sort, but they're software that runs, tests, or delivers other software or even orchestrates the operations of an entire environment shared by many different applications. This inevitably means a whole lot of your work is the classic incident respon…