There are reports produced that developers don't get to see that the manager does to compare developers this way.
Of course, this can be easilly gamed. The most cunning developers will go out of their way to get the tasks that are clearly defined in scope and that they are familiar with, while others always end up getting the short end of the stick.
Guess who is going to look better under that report. Developers are overloaded, and will actually avoid to raise new issues or suggest improvements and new tasks, with fear that they will get more work on top of the workload that they can't already handle.
JIRA is really used by middle management to treat developers as essentially replaceable assembly line workers in a factory context.
I think the more fundamental issue is that most businesses that existed before and after digitization don't really understand or appreciate that they are alive because of that transformation.
Most tech enabled companies do not understand that competent IT execution is important to their ability to have freedom of movement and the ability to respond to change in their markets.
Also Developers think developing is important, but also business thinks business is more important and they got by with paper and phones for a long time before computers turned up.
Both are fair points.
I would say that quality of life at work (in tech) is a function of how much the business thinks that the work you do is important. Is IT a cost center or a capability factory where you work?
In start ups and tech focused companies the core work is technology so it's easy to understand the investment. But places where IT isn't core work, developers are just cogs. They get treated like crap and are made to sprint because who cares, the 'actual' business is important.
Lastly, IT workers talk a big game about Unions but I'd really like to see the day where a strike by IT workers starts with them walking off the job after turning off the network.
I think Atlassian is the Uber of the software development process and devs are the drivers.
Death by metrics isn't the fault of Jira--Jira provides tools to do many things more effectively, and gathering metrics is just one of those. Providing effective tools to ineffective people, unfortunately, does allow those people to shoot themselves (and in management's case, everyone around them also) in the foot more easily.
Exacerbating this, as you mentioned, is that metrics do provide a simple, cheap representation of productivity, even if that representation is not aligned with reality. Middle management can present this to upper management to show that they're doing a "good" job, and upper management will be none the wiser about what's not exposed by the metric until a while down the road when problems created by optimizing for those metrics become more apparent.
We use JIRA and we find it extremely useful, although we never use real-time values for estimates or reporting. Story points, which I believe are recommended by the Agile framework, are used to estimate and draw burn down charts and reports. We can then use these to adjust our estimates for future sprints.
JIRA really is a tool and just because some managers use it poorly, doesn't mean that is why it was created. Those managers would be bad regardless of the tool.
One project is in Sprint #17 this week.
One is on Sprint #41 as of Wednesday.
One is on Sprint #56 as of this Friday. On top of that, the weekly meeting is set at 4:30pm on Fridays in my time zone. The sprint planning meetings typically go 2 hours.
Each project has a daily stand-up too, each lasting about 30-45 minutes. I get about 3 hours a week total to actually code.
Yes, this has effectivly killed the entire idea behind a sprint and agile in general, we all know, it's super obvious. But the company is now an 'agile' company as of ~2.5 years ago, so we can say so in the job apps. All the interviewing devs know to ask about how long the stand-up is, we tell them the truth, and the job apps stay open when they decline our offers (we also pay under market rates). Our copies of 'The Phoenix Project" remain in shrinkwrap.
Majority of managers will always be mediocre. But previously, managers without tool just let the developers do the job. Nowdays, mediocre managers have industry standard tool to make everyone life terrible and destroy the product by accumulating bad decisions founded on jira/agile metrics.
Also, jira and agile gives management ability to be extremely shorter oriented in their reasoning - that is major factor changing dynamic in the team.
A team that is doing agile right is not "sprinting", they are completing as much work as they can do at a long term sustainable pace.
Oh, please stop with the "because you're doing it wrong" defense. Yes, I most likely am doing it wrong, I already know that. Is the fact the process allows the level of flexibility for me to screw up this bad a feature or a bug?
I'd love the opportunity to practice Pedantic Agile but things like customers, coworkers and bosses keep getting in the way.
why would it it be "above sustainable pace".
Humpty Dumpty smiled contemptuously. 'Of course you don't — till I tell you. I meant "there's a nice knock-down argument for you!"'
'But "glory" doesn't mean "a nice knock-down argument",' Alice objected.
'When I use a word,' Humpty Dumpty said, in rather a scornful tone, 'it means just what I choose it to mean — neither more nor less.'
-- L. Carroll
High-intensity long-haul efforts can require months of recovery, or be permanently crippling.
The 100m world record is 9.58s. The world-record marathon pace, 17.2s/100m. The Race Across America 3,000 mile bike race record, a sustained speed of 12.57 mph, or 17.8s/100m.
The specific physiological mechanisms for physical and mental exhaustion differ, but the general principles are similar: metabolites, waste products, side-effects, and damage accumulate. Absent a period of rest and recovery, these will eventually prove damaging.
In sport training, there is a carefully calibrated set of activities and rest and recovery, ranging from in a given motion (power and recovery stroke in running, cycling, swimming, rowing, or virtually any other action), to exercises, efforts, sets, workouts, seasonal, and lifetime scheduling.
Speed, skill, and muscle aren't created on the track, in the pool, on the road or trail, or at the gym, they're created in bed, when you're asleep, during recovery, given adequate nutrition. Training is stress, but a stress that's calibrated to trigger a conditioning response.
If you don't get rest, you'll simply break down.
But these sprints normally are done repeatedly with no actual stop or sight of a finish line.
Employees just churn through tickets with no designed breathing room or planned downtime. Jira is probably one of the biggest helpers at causing burnout with all of those burn down charts and story point comparisons, driving companies and employees to not support taking reasonable time off or spending time at lower pressure to encourage employee wellbeing.
Basecamp’s team wrote a guide to their take on this process and why they rejected it called “Shape Up” which seems pretty pie in the sky but makes some incredibly good points on maintaining team happiness, culture and quality of work.