Why is Atlassian resistant to providing tools for understanding how well people perform?

[Nord Carverson]

I've used jira for I guess more than 8 years now and it's always seemed to be an uphill climb to understand both the team and individual performance. More - it has always seemed Atlassian would prefer you didn't. 

I understand the variables and that raw figures are not the whole story.

But having autonomy over work, accepting and committing to it gives teams and individuals a freedom that doesn't come when the default view is vague. At the executive level development is seen as a dark art and viewed suspiciously. And this is exaggerated when there is difficulty in providing transparency against originals and things like tracking of hours for billing. Without add-ons, or exporting and manipulating data.

Like others I've worked out a few ways around it, I just don't understand why Atlassian seems to work against it. Kanban boards currently don't even allow for estimation in their settings.

Is this a deliberate decision by Atlassian and if so, why?

[Nic Brough -Adaptavist-]

I suspect there's several reasons that Atlassian don't do this.  I can think of a couple, but there are almost certainly others, and I'd like an Atlassian to comment too.

• My first thought is that there are some add-ons that do this sort of reporting.  Atlassian mostly (but not always) don't add features that are already covered by add-ons unless they think that the feature really should become part of the core functionality.
• Team.  Atlassian emphasises teams, not people.  I could write an essay on my experiences with the teams I've felt that I was part of, and not, and maybe, and "you say team... but...".  But meh.  Concentrate on your team.  What works for them and you?  Individual reporting to compare team members?  Performance metrics? Lines of code turned out?  Personally, I'd go for "When someone says 'team lunch' we spend 4 hours working out the best place and then talking while we eat".  Which can't be reported on an individual level in Jira.
• Atlassian's second largest marketplace has laws that make reporting on individuals like that quite "difficult".  Or rather "illegal unless you get permission" which is almost impossible to get past the work councils.

[Nord Carverson]

Yes there are add-ons. And that's the solution.

But Atlassian don't just not provide it, they actively resist it. Right now in new projects on my cloud instance I get story points on issue layouts where the screens I've defined for them don't even contain that field. Its origin is a mystery - Atlassian added it contradicting my scheme because they know better. That's a little odd .. and contradictory. Plainly suggestive of their philosophy.

And their new next gen projects have only points with no time tracking - not even an option from what I can see. Everywhere I've worked the people who pay the bills don't want to tip money into development which isn't transparent. And why should they?

You mentioned laws in the marketplace - what do you mean?

[Nic Brough -Adaptavist-]

The next-gen stuff is still under development so I don't think it's "resisting", it's more "not done it properly yet".  Personally, I don't think Next-gen is even ready for most of us yet, there's so much missing, including time tracking.

As for the laws, I mean the laws in Germany (Atlassian's second biggest marketplace) prevent individuals being tracked in software in most cases - it's ok to measure team performance, or project, or business unit etc, but try to put in software that might report on individuals and you butt straight into the privacy laws.

For a rough idea, have a look at how onerous the GDPR is across the EU.  GDPR could be seen as a watered-down implementation of a sub-set of the individual privacy rights people have in Germany.

[Andy Heinzer]

The kanban methodology has a considerably different from scrum.  Both are frameworks in which you can practice agile, but they have different roles, different key metrics, and a different driving philosophy behind them.  

To better understand Atlassian's approach to each of these, I would recommend reading https://www.atlassian.com/agile/kanban - What is Kanban?

and the counterpart of

https://www.atlassian.com/agile/scrum - What is Scrum?

I really like this chart from the Kanban page to help explain how these differ:

Scrum vs. kanban

Kanban and scrum share some of the same concepts but have very different approaches. They should not be confused with one another. 

	SCRUM	KANBAN
Cadence	Regular fixed length sprints (ie, 2 weeks)	Continuous flow
Release methodology	At the end of each sprint if approved by the product owner	Continuous delivery or at the team's discretion
Roles	Product owner, scrum master, development team	No existing roles. Some teams enlist the help of an agile coach.
Key metrics	Velocity	Cycle time
Change philosophy	Teams should strive to not make changes to the sprint forecast during the sprint. Doing so compromises learnings around estimation.	Change can happen at any time

These pages offer better explanations at a high level as to why each behaves the way they do, and to some degree how Atlassian has interpreted these ideologies. 

In short, Kanban doesn't offer estimations because it's focused on work that is actively in progress.  For Kanban it is more about the cycle time in the project, and less about the estimating a time to complete a task.  In turn, Kanban can help you visualize the work in progress and identify bottlenecks in the process itself. 

Conversely Scrum is more geared towards continuously improving.  Estimations are more essential to scrum and the scrum master's ability to gauge the work requirements.   Those estimations are not a stone contract of time commitments, they are there to try to help the scrum master get better at estimating based on a number of factors over several sprints/iterations.  Scrum masters are not expected to be accurate estimators from the get go. 

I hope that helps explain why Kanban will have different features here.  But I fear that my explanation might not have yet addressed your source question here.

In regards to your title question, I'm not sure that I'm qualified to answer on behalf of Atlassian for the broader topic itself.  But I suspect it goes back to one of Atlassian's company values, which is to play as a team.  There is far more focus in Atlassian to work as a team, rather than to try to measure each individuals contribution levels in a project.   There are ways to do it, but it has not been the focus of Jira to do this.  Which is probably why it has been left to other vendors to offer solutions here instead.  

Since you mentioned measuring team performance, have you tried using Jira Portfolio?  It has a number of additional features that build on top of our Jira Software product try to help provide long term road map planner, and team capacity views.   I'm not sure if this would be helpful to you here, but perhaps it's worth looking into to see if it might help provide some more transparency to stakeholders.

[Nord Carverson]

Thanks Andrew, I appreciate you taking the time. Portfolio is definitely overkill, yeah.

Atlassian's resistance to an understanding of how efficiently even teams work is the missing piece. No matter the methodology it is a benefit to be able to compare estimates to actuals, see where time goes, know which tools and approaches work efficiently, understand who deserves recognition and who may need support.

Atlassian's choice is plainly to ignore that opportunity. Anyone with time or financial pressures needs this information. From the outside jira is seen as developer paradise where dates, times and budgets aren't important. It's all about the process and code quality. That's a little selective. It is about that but not just that.