Hacker News Reader

Comment by agloeregrets | Hacker News Reader

What is funny about this is that Atlasssian’s Jira product is designed for two week “sprints”, a term referring to the idea of running quickly at a rate above a sustainable pace with no intent to keep running after the end.

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.

View on HN

In JIRA your performance is constantly measured comparing the actual work against the estimates, which are usually not under the developer control.

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.

You should say "In JIRA your performance could be measured"...

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.

I'm a big critic of Jira for this reason.

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.

It doesn't have to be that way. We use it mainly as a tool to track issues and move these issues through a workflow. When I was scrum master one of the first things I did was to stop tracking time and we didn't enter story points or anything. Personally I would be very interested in numbers how much things take to learn estimating better but I know the numbers will be abused by some managers so it's better not give them any data that could be abused.

Management by "make metric go up" is almost always terrible in every situation, since human misery is generally not considered an important metric (too hard to measure!) and metrics themselves cannot expose long-term consequences of optimizing for a metric at the expense of anything that isn't being measured.

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.

Yeah, I'm in the middle of 3 projects right now using sprints as the base time unit.

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.

This problem has nothing to do with Jira or agile, but with bad management.

No. Problem is with jira and agile.

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.

Again. The problem is with management.

They're called "iterations" over here and it's probably precisely because of that implication. It was always an unfortunate term.

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.

>> A team that is doing agile right ...

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.

Pedanticness is beside the point here. You don't have to follow every ceremony to get the basic point of "you cannot sustain a pace that works your programmers like Victorian pit ponies".

> “sprints”, a term referring to the idea of running quickly at a rate above a sustainable pace

why would it it be "above sustainable pace".

That is literally the definition of the word. If you can run for more than, at most, a minute or so at a given pace you are pr. definition not sprinting.

Isn't any running unsustainable though ?

Not really. Google ultramarathoning, Humans are incredibly well designed to run long distances at a sustained pace, it's like the one other thing we rock at better than other animals other than intelligence.

A sprinter is wasted after 100m. A marathon runner is wasted after 26.2 miles. Then there are the ultra marathoners. I believe the analogy holds.

Humans evolved to be really good at long distance running and given proper training, time and discipline you can run an absurd distance compared to most mammals.

Sprints also have a specific meaning in Agile/Scrum vocabulary which should be pretty common around here. That's like suggesting github promotes physically aggressive behavior because it's centered around pushing. Nothing about a sprint in Scrum terminology is meant mean an unsustainable pace.

'I don't know what you mean by "glory",' Alice said.

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

What can be sustained for a short effort is not sustainable over a longer haul.

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.

Reply on news.ycombinator.com