4 ms·

My goto example of a dysfunctional and bureaucratic organization is an example I saw in a finance company I worked for. I was a on team that we were doing a ma

My goto example of a dysfunctional and bureaucratic organization is an example I saw in a finance company I worked for. I was a on team that we were doing a major project. We basically ran Kanban but had to run "sprints" so we chose 4 week sprints to get it out of the way and we put everything on the board we had to get done that month to stay on track. Our pipeline was setup in such a way that you were required to have a jira ticket to push a commit. We were really crushing our timeline, doing 2x the work we were expected, a really great team honestly. But we opened up bugs and additional features in the middle of our sprints to track our work as we did it. What this amounted to was maybe us saying we have to do 40 tickets this month, and wed be closing like 80. 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. They wouldn't give up on this, and said it was our fault for not estimating better (which sure, but we were beating expectations!). So we did the reasonable thing and improved our estimates! 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.

tokyolights2 2y ago
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.
- aiisjustanif 2y ago
  Could have spent that time more wisely by making a better graph that accounts for this…
FireBeyond 2y ago
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".
constantcrying 2y ago
>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.
- loloquwowndueo 2y ago
  It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level. The team that decided to do this to keep the metrics happy rocks, though :)
  - constantcrying 2y ago
    >It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level. Have you seen actually dysfunctional organization? Millions being burned over ridiculous mismanagement. Bureaucracy which takes up vast amounts of time. Tracking of completely meaningless metrics. An IT department which needs to be "worked around". Managers who's only interaction point is them asking you what they should write into their MS Project document. Constant shifting away of responsibilities. People making completely unqualified decisions over the heads of the actual people being concerned. Inter department conflicts. Really I could go on, but a bit of massaging metrics (which are totally irrelevant anyway and their trackers can be safely fired) is not particularly bad.
    - sodapopcan 2y ago
      The person you are responded to said it's a sign of dysfunctional org, not that it by itself make an org dysfunctional. There is a huge difference.
      - constantcrying 2y ago
        >The person you are responded to said it's a sign of dysfunctional org He said it was his go to example of dysfunction.
apozem 2y ago
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.
- cruffle_duffle 2y ago
  > If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. LOL, just joined a team that seems to be doing exactly what you describe. You start attaching performance incentives to how tickets are estimated and closed... people are gonna game the fuck out of them.
  - morkalork 2y ago
    I used to work somewhere that different bug severity levels were a KPI. One day after opening some prod/blocker/whatever level bug, I got a slack message from some useless agile coach arguing over it. After that, I created one kind of ticket in Jira. Fuck it. And when I talked to another senior engineer on another team it turns out they had the same experience and came to the same conclusion.
- sailorganymede 2y ago
  Strange… The finance company I work at also does this. And it’s so strange. I feel like they value Jira tickets more than actual work being done. It’s even funnier cause we get asked to close work when we want to go into prod and told to create new tickets to put our work in to prod. which kind of is annoying.
- ryandrake 2y ago
  Careful, though, because you may encounter someone who can sniff out these tricks. I worked at a place where, like many companies, tracked the bug burndown as one of the measures of project risk. So, the closer you got to the release, the fewer bugs were expected to be open. Having many bugs open early in the project was fine and encouraged. Having few bugs open towards the end was seen as On-track, and having many bugs open towards the end was a red flag, where the program might want to either step in and help organize things or at least raise the risk with higher management. This is a pretty standard scenario you get at a lot of software companies. Well, one of the teams realized that if they just kept their bug count always at zero, they'd never be bothered by those nasty, annoying project managers. So that's what they did. They were constantly in crisis, fixing problems and committing code, but their bug counts always looked great. A trivial bug tracker query revealed what they were doing: They'd just keep a side bug tracker in a doc rather than filing them in the real tracker, and then seconds before committing the code, they'd quick create a bug and use that as the required bug in the commit message. So, the following week, these "ninja bugs" were added to the automated reports, and that behavior ended quickly.
siva7 2y ago
> 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?
- ecshafer 2y ago
  This was a team of 10 people, so costing the company $2M+ a year. How is halving the timeline on a very major, mission critical project not a good thing? Some appendage management structure in the organization having charts and reports looking a certain way is secondary to how much value is being produced by a team of expensive engineers.
- gopher_space 2y ago
  Am I working for The Tacoma Chart Co. or are we developing actual products here?
- adammarples 2y ago
  Because the burn down charts don't matter and the real work being done twice as fast does matter.
riskable 2y ago
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 managers makes you look like you know what you're doing (LOL).
- gspencley 2y ago
  > "Your inability to adequately track my team's weekly or monthly performance is not my problem." I'm an engineer and I can certainly understand and empathize with where that sentiment comes from. However, when people say things like this the first thought that goes through my head is "there is a culture problem." That sentiment underscores an adversarial relationship between teams and leadership/management. That adversarial relationship should never exist (it does all too often, but it shouldn't). Tracking timelines and deliverables is something that requires communication. That communication can be automated, but it's not up to leadership or management to implement that automation. They are not the engineers. So if the process that is in place, which has worked for them despite inefficiencies (which they may not be aware of) is suddenly disrupted then no, it is not only "their problem." Some team went and did something differently than how things are usually done. The team [rightfully] recognizes that it is an improvement, but it was unsolicited and the communication / warning of the upcoming change was likely lacking. Companies are called "companies" for a reason. They involve multiple people with varying skill-sets, responsibilities, understanding of how things do and should work, they have their own pressures and reporting structures (they need to hand things over to their management who expects a certain status quo as well) and most people have a default low tolerance for change. This is no one person's fault. The company culture needs to facilitate iteration, improvement and innovation.
Aurornis 2y ago
> 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't 100% guarantee that it would be done by the end of the sprint it posed an existential threat to the Program Managers' charts, and therefore their bonuses. Program Managers wouldn't come out and say any of this, of course. They knew the situation was at odds with delivering software quickly. However, if you deviated from the plan they would pull you into meeting after meeting for hours and hours to try to keep you in line. If you opened a new ticket mid-sprint, you'd get pulled into meetings with Program Managers to justify it. They'd argue and debate and cajole you into deleting the ticket and rolling it into something halfway related. They'd CC your manager on 5 different e-mails and check in multiple times a day to make sure you'd fallen in line. It was hell. Weirdest part to me was how many people around me seemed to enjoy that structure. They recognized the game and gladly played along, delivering a couple hours of work each day and then sitting in meetings to talk about it for the rest of the time. It all came crashing down about 18 months in, when management brought in someone who actually understood software development and started actually looking into what people were doing. I was gone by then, but they went slash and burn on the remaining department. They cut it down to 1/5th of the size and started delivering, as far as I can tell, the same amount of work.
nonameiguess 2y ago
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 response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works. Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants. But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do. But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature. So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.
hinkley 2y ago
It's funny that my anecdote also comes from a kanban team, but amongst mostly waterfall people and one Scrum nutjob. When you are showing people up they throw the book at you. Yes you're getting a lot done but you're cutting corners so that's cheating! In an org that is perpetually behind schedule they rely on one team being a scapegoat for why all the other teams are behind schedule, and when your team has never been more than 10 days behind it stings. One of my proudest moments on that project was when I figured out a judo move to meet (and exceed) the documentation requirements for our part of the project with less than 3 man hours per milestone after I got it working (and half of that was typesetting fixes by one of our tech writers). I got the impression that the person who called it out was really hoping it would cost us 20-60 hours per milestone. I think I spent about 30 hours total, including the initial set up time for the tools and templates. So their gambit only worked for a single milestone and then it was back to the races.
- specialist 2y ago
  > Yes you're getting a lot done but you're cutting corners so that's cheating! Yup. Merits of Agile aside, I don't recall any of the project/product management books preparing noob me for the organizational (and personal) psychology stuff. As you surely know, this is what the gray beards mean when they say most challenges (obstacles) to shipping software are not technical.
imtringued 2y ago
>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 Seems like someone has become aware of the power of liquidity and delayed decision making giving one the ability to respond to future information.
araes 2y ago
I like how the response was "falsify the metric data" because an ape in a suit somewhere demanded a "correct" metric. And were rewarded for their falsification. There's an Aesop's Fables story in there somewhere. I wonder how many metrics people depend on, like jobs data, get the "change the data" to suit ape in suit's needs?

tokyolights2 2y ago

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.

aiisjustanif 2y ago
Could have spent that time more wisely by making a better graph that accounts for this…

FireBeyond 2y ago

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".

constantcrying 2y ago

>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.

loloquwowndueo 2y ago
It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level. The team that decided to do this to keep the metrics happy rocks, though :)
- constantcrying 2y ago
  >It’s called gaming the metrics and it’s totally a sign of dysfunction at the org level. Have you seen actually dysfunctional organization? Millions being burned over ridiculous mismanagement. Bureaucracy which takes up vast amounts of time. Tracking of completely meaningless metrics. An IT department which needs to be "worked around". Managers who's only interaction point is them asking you what they should write into their MS Project document. Constant shifting away of responsibilities. People making completely unqualified decisions over the heads of the actual people being concerned. Inter department conflicts. Really I could go on, but a bit of massaging metrics (which are totally irrelevant anyway and their trackers can be safely fired) is not particularly bad.
  - sodapopcan 2y ago
    The person you are responded to said it's a sign of dysfunctional org, not that it by itself make an org dysfunctional. There is a huge difference.
    - constantcrying 2y ago
      >The person you are responded to said it's a sign of dysfunctional org He said it was his go to example of dysfunction.

apozem 2y ago

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.

cruffle_duffle 2y ago
> If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. LOL, just joined a team that seems to be doing exactly what you describe. You start attaching performance incentives to how tickets are estimated and closed... people are gonna game the fuck out of them.
- morkalork 2y ago
  I used to work somewhere that different bug severity levels were a KPI. One day after opening some prod/blocker/whatever level bug, I got a slack message from some useless agile coach arguing over it. After that, I created one kind of ticket in Jira. Fuck it. And when I talked to another senior engineer on another team it turns out they had the same experience and came to the same conclusion.
sailorganymede 2y ago
Strange… The finance company I work at also does this. And it’s so strange. I feel like they value Jira tickets more than actual work being done. It’s even funnier cause we get asked to close work when we want to go into prod and told to create new tickets to put our work in to prod. which kind of is annoying.
ryandrake 2y ago
Careful, though, because you may encounter someone who can sniff out these tricks. I worked at a place where, like many companies, tracked the bug burndown as one of the measures of project risk. So, the closer you got to the release, the fewer bugs were expected to be open. Having many bugs open early in the project was fine and encouraged. Having few bugs open towards the end was seen as On-track, and having many bugs open towards the end was a red flag, where the program might want to either step in and help organize things or at least raise the risk with higher management. This is a pretty standard scenario you get at a lot of software companies. Well, one of the teams realized that if they just kept their bug count always at zero, they'd never be bothered by those nasty, annoying project managers. So that's what they did. They were constantly in crisis, fixing problems and committing code, but their bug counts always looked great. A trivial bug tracker query revealed what they were doing: They'd just keep a side bug tracker in a doc rather than filing them in the real tracker, and then seconds before committing the code, they'd quick create a bug and use that as the required bug in the commit message. So, the following week, these "ninja bugs" were added to the automated reports, and that behavior ended quickly.

siva7 2y ago

> 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?

ecshafer 2y ago
This was a team of 10 people, so costing the company $2M+ a year. How is halving the timeline on a very major, mission critical project not a good thing? Some appendage management structure in the organization having charts and reports looking a certain way is secondary to how much value is being produced by a team of expensive engineers.
gopher_space 2y ago
Am I working for The Tacoma Chart Co. or are we developing actual products here?
adammarples 2y ago
Because the burn down charts don't matter and the real work being done twice as fast does matter.

riskable 2y ago

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 managers makes you look like you know what you're doing (LOL).

gspencley 2y ago
> "Your inability to adequately track my team's weekly or monthly performance is not my problem." I'm an engineer and I can certainly understand and empathize with where that sentiment comes from. However, when people say things like this the first thought that goes through my head is "there is a culture problem." That sentiment underscores an adversarial relationship between teams and leadership/management. That adversarial relationship should never exist (it does all too often, but it shouldn't). Tracking timelines and deliverables is something that requires communication. That communication can be automated, but it's not up to leadership or management to implement that automation. They are not the engineers. So if the process that is in place, which has worked for them despite inefficiencies (which they may not be aware of) is suddenly disrupted then no, it is not only "their problem." Some team went and did something differently than how things are usually done. The team [rightfully] recognizes that it is an improvement, but it was unsolicited and the communication / warning of the upcoming change was likely lacking. Companies are called "companies" for a reason. They involve multiple people with varying skill-sets, responsibilities, understanding of how things do and should work, they have their own pressures and reporting structures (they need to hand things over to their management who expects a certain status quo as well) and most people have a default low tolerance for change. This is no one person's fault. The company culture needs to facilitate iteration, improvement and innovation.

Aurornis 2y ago

> 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't 100% guarantee that it would be done by the end of the sprint it posed an existential threat to the Program Managers' charts, and therefore their bonuses. Program Managers wouldn't come out and say any of this, of course. They knew the situation was at odds with delivering software quickly. However, if you deviated from the plan they would pull you into meeting after meeting for hours and hours to try to keep you in line. If you opened a new ticket mid-sprint, you'd get pulled into meetings with Program Managers to justify it. They'd argue and debate and cajole you into deleting the ticket and rolling it into something halfway related. They'd CC your manager on 5 different e-mails and check in multiple times a day to make sure you'd fallen in line. It was hell. Weirdest part to me was how many people around me seemed to enjoy that structure. They recognized the game and gladly played along, delivering a couple hours of work each day and then sitting in meetings to talk about it for the rest of the time. It all came crashing down about 18 months in, when management brought in someone who actually understood software development and started actually looking into what people were doing. I was gone by then, but they went slash and burn on the remaining department. They cut it down to 1/5th of the size and started delivering, as far as I can tell, the same amount of work.

nonameiguess 2y ago

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 response/post-mortem of operations, plus some level of customer support given to other development teams because internal platform teams never get a separate support organization. To this day, the government has no idea how to handle this in light of how DFARS (administrative law governing acquisition) works. Every labor hour a contractor charges has to be tied to a specific line of accounting which is itself tied to some unit of planned work tracked in an issue tracker or project management system of some sort. Most of the time, this is an Epic in Jira. This is logical insofar as you consider the intention of acquisition as a category of appropriations bill. A budget proposal with line items tied to measurable product features is presented to and approved by Congress. You have to demonstrate you're spending the money they gave you on what they approved you to spend it on, because per the Constitution, that's how power of the purse works. The executive branch can't just do whatever it wants. But it falls apart as contractor labor increasingly replaces federal civil servants. When your job is anywhere from half to all running and maintaining an operational system, that isn't really acquisitions any more. It's operations and maintenance, which is an entirely separate appropriation. Soldiers manning a defensive perimeter have no idea when they're going to be attacked or how much work they'll be putting in. Software operations is effectively just the less lethal civilian equivalent of that. The government arguably even recognizes this in many ways. Typically, running and maintaining the production system is a separate contract from the development contract and it uses separate work tracking systems, and if someone spends 8 hours watching a screen while producing no quantifiable work outputs, so be it. They charge 8 hours because that's what the contract says they're supposed to do. But as we're increasingly expected to be modern software organizations with things like CI/CD, test and staging environments, and you inevitably need to run at least some of your own development infrastructure, well now what? You have a lot of people whose job is the same. Be on constant lookout and respond as needed, but now it's part of a development contract and they need to have quantifiable work outputs that be tied to a budgetary line item with an associated product feature. So we convolute nonsense out of thin air like cloning the same monthly "Support" Epic in Jira, month after month. "As a developer, I want my tooling to work so I can do my job and deliver value to the government." Plug in some SWAG number vaguely guessed at based on how much of this kind of work you ended up doing last year. Every 90 days, play planning poker with it. LARP a product team even though that isn't what you are.

hinkley 2y ago

It's funny that my anecdote also comes from a kanban team, but amongst mostly waterfall people and one Scrum nutjob. When you are showing people up they throw the book at you. Yes you're getting a lot done but you're cutting corners so that's cheating! In an org that is perpetually behind schedule they rely on one team being a scapegoat for why all the other teams are behind schedule, and when your team has never been more than 10 days behind it stings. One of my proudest moments on that project was when I figured out a judo move to meet (and exceed) the documentation requirements for our part of the project with less than 3 man hours per milestone after I got it working (and half of that was typesetting fixes by one of our tech writers). I got the impression that the person who called it out was really hoping it would cost us 20-60 hours per milestone. I think I spent about 30 hours total, including the initial set up time for the tools and templates. So their gambit only worked for a single milestone and then it was back to the races.

specialist 2y ago
> Yes you're getting a lot done but you're cutting corners so that's cheating! Yup. Merits of Agile aside, I don't recall any of the project/product management books preparing noob me for the organizational (and personal) psychology stuff. As you surely know, this is what the gray beards mean when they say most challenges (obstacles) to shipping software are not technical.

imtringued 2y ago

>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 Seems like someone has become aware of the power of liquidity and delayed decision making giving one the ability to respond to future information.

araes 2y ago

I like how the response was "falsify the metric data" because an ape in a suit somewhere demanded a "correct" metric. And were rewarded for their falsification. There's an Aesop's Fables story in there somewhere. I wonder how many metrics people depend on, like jobs data, get the "change the data" to suit ape in suit's needs?