> I have no beef with JIRA per se, but its the one we come across the most.
> Here’s what a colleague said, just this morning about JIRA:
>> We must ensure JIRA usage is identical across teams, in order to ensure velocity parity
> So, clearly this is no fault of JIRA — I (as I’m sure you) have seen it used many a time successfully, but all to often, it is used (and abused) as a top down management tool, mandated from the centre.
Uh... then don't work for company with shitty management... This has absolutely nothing to do with JIRA. You could find and replace 's/JIRA/Rally/' and while the article would still be wrong it would make as much sense. There is nothing inherently wrong with JIRA itself. If you have shit management then you have shit management and no tool is going to help/hurt that really...
I actually ask during interviews if a company uses any type of Agile/Scrum/Kanban/"sprint cycle" workflow or uses JIRA/Asana/other Agile-focused metric trackers -- and immediately reject doing any more rounds of interviews with that company if they do. I'd say about 80% or so of the companies I speak to get rejected immediately just for this reason alone.
I've found that this is one of the very best indications that a given company has dysfunctional management, doesn't prioritize engineering quality or craftsmanship, views software labor as a cost center of the business instead of a value center, and views programmers as easily replaceable commodity workers.
I totally grant that it's possible I am passing on some good companies when I do this. But the false negative rate has to be extremely low, since so many other companies with these tools have repeatedly demonstrated themselves to be horribly managed, talent-wasting career killers. I'm happy to suffer the false negative rate just to be super safe that I don't end up in another such place in my career. And to boot, even though I've turned down follow-up interviews with many places because of this, I've never regretted doing so, and have often learned after the fact that there was significant engineering dysfunction in that firm from other sources.
I would really love it if either DeMarco & Lister (who wrote Peopleware) or Jackall (who wrote Moral Mazes) would add new sections to their books specifically about the invalidity of Agile-like management techniques, and the way they are used for 'dexterity with symbols' (as Jackall puts it in Moral Mazes) to create political arguments for micromanagement and keep developers distracted, while devaluing their labor and disconnecting the field from the spirit of craftsmanship.
In some cases, I have known other people who worked in the companies and attested to the poorness of the work environment, or been able to read large and very public accounts of employee discontent within them.
Another good indicator of the same things is the unnecessary use of open-plan offices, especially if combined with a lack of willingness to permit significant time working from home.
Right and as it says in the title, use of JIRA is often a symptom that there is a problem with management. Nowhere is it stated that JIRA itself is the problem.
I disagree. JIRA goes further out of its way to accomodate Agile/Scrum stuff than many other issue trackers. I was on a team once where we used FogBugz (without any of the metric tracking nonsense -- our managers didn't even log in to it, they just talked to us when they needed to know about progress) for a long time without any issue, and only after some big middle management restructuring did we switch to JIRA, specifically because managers wanted a tool that spit out useless junk about velocity and burndown. We even had to go and do really dumb training about "story points" and how to enter the progress data they wanted (which added so much overhead to entering things into the system that most of us just stopped, or at least cut every possible corner so as to not waste our time doing manual data entry for the sake of middle management).
Not every such tool focuses on these kind of pointless metrics so much. Using the GitHub issue tracker is joyful, especially when you don't have someone trying to micromanage you with it. Some tools focus instead on what the actual developers need to get their work done, instead of what managers want in order to be more micromanagerial.
Another tool that is starting to go down the dark path of JIRA is Asana, which is a shame because the original design of Asana was great. But now it's all about Scrum metric bullshit, catered to middle managers who have the power to choose it over other things, and usually don't make the choice based on developer preferences or rational arguments.
I'd say the title could be "Agile/Scrum metric trackers are a symptom of a management problem" and that JIRA is absolutely the poster child for such a tool, so it's not bad faith to tie it directly to JIRA. Though your point does bear repeating: JIRA is not the only tool that suffers from this problem.
It is "failure to use issue tracker effectively" and it happens all the time.
The problem is confounded by many little cuts. For instance, they think that the issue tracking system is only used by devs, so it goes on a dust-filled desktop machine from '03 that is stuffed in a corner somewhere, so it is underpowered and takes 25 seconds to load a page over my DSL connection and about 22 seconds at the office.
The people at the office don't care, however, because the boss thinks the issue tracking system is a waste of time. He bitches me out for taking 10 minutes to write up an estimate and then giving an estimate which is always "too long." I am carefully watching the star programmer to understand what he does right, and finally realize the reason he doesn't have this problem is that he doesn't estimate anything. Sometimes the testers put in tickets, and sometimes the star programmer puts one in, but the "product owner" never puts one in or bothers to show up at the scrum meetings down the hall.
Top management assigned a project manager to our team and she was putting in the scrum thing because my team had been going in circles for two years and they had to get a product in front of the customer. My boss pushed her out and she left to work for some kind of Christian charity.
At some point our boss got the religion of checklists, gave up on the idea of estimating or scheduling, and somehow we got it across the finish line.
But you can't say the same about every issue tracker. For example, GitHub Issues is so constrained that it's difficult for management to bend it, for good or ill.
I followed a few links, and didn't see much background information about Ben's experience with companies using JIRA at scale; from the tone of the posted sounds like he is seen some bad management and action.
But here's another point of view; at work we (among other things) train and consult companies on effective use of JIRA. As best we can tell, our students and clients are well-intentioned, trying to use JIRA for good, not for evil. They often want something similar to what Ben wrote about, to get numerous projects and teams across a large organization using the same tracking tool (JIRA) in approximately the same way, with local variations as needed but avoiding pointless variations.
I've actually not heard of any of them trying to "ensure velocity parity", but rather the typical goal is to be able to roll up and understand project status and progress across a large and sprawling organization working on goals that far exceed what an individual team could do. This seems like a worthy and important goal.
> able to roll up and understand project status and progress across a large and sprawling organization working on goals
The major problem with that is we are incredibly good at gaming the system. I've seen mediocre, at best, team became a glowing beacon under the velocity game; they managed to close 2000+ stories in one year! (a developer closed well over 1 story per day on average).
Software estimation is a really hard problem. We can attempt to establish order by pretending that burning down/velocity charts actually say something useful. How do they work when all the methods we know fail? No idea. But have faith, because we have plenty of anecdotes of its success!
Sounds like a shitty company, you're probably missing much bigger symptoms.. Get a new job
JIRA is [s]fine though[/s] ok, I've used when at a HN hip company, and it worked really well, granted it could have been a little simpler, but still much better than any homegrown alternative, and it was on-premise too.
Clojure use it to track issues too, and very few moans (surprising given the amount of hammock time devoted to simplicity)..
Disclaimer: At one point prior to using JIRA I did retweet '"Im so happy we use JIRA" - no programmer ever' or something like that, cargo-culting jira hate?
The author has an incorrect definition of Taylorist management.
> Now obviously this is a blatant transgression — absolute, unequivocal application of Taylorist management in the context of a Product Development mindset
From the Wikipedia article that HE LINKS, this caveat is given as to why Taylorist principles still sometimes apply:
> Although scientific management as a distinct theory or school of thought was obsolete by the 1930s, most of its themes are still important parts of industrial engineering and management today. These include analysis; synthesis; logic; rationality; empiricism; work ethic; efficiency and elimination of waste; standardization of best practices.
And that's what JIRA is used for in most companies.
> [Taylorism] include analysis; synthesis; logic; rationality; empiricism; work ethic; efficiency and elimination of waste; standardization of best practices.
To be fair, you have to accept that Taylorist doctrine states very emphatically that analysis, synthesis, logic and rationality are the exclusive domain of management. Boss's responsibility is to think very thoroughly about how work is to be done, and worker's responsibility is to do exactly as told. In Taylor's work it goes as far as to dictate how ofter and for how long workers are to take breaks (so the maximum amount of labor can be extracted from them without exhausting their muscles before the end of the shift).
To complete your list, empiricism and work ethic are the tactics that are to be used to apply all that management's brain power; efficiency and elimination of waste are the end results; and standardization and best practices are the institutionalization of those end results so that the manager's enlightened intelligence can move on to "fine tune" the next process in the assembly line.
I am not saying that there is no use of standards and best practices. If anything, in the software industry we need to be more strict, not less, about the best practices we already know and have known for several decades. But there is a big difference between that and the kind of micromanagement that this kind of tools elicit in practice.
i.e. Professional athletes do need to drill until individual movements become second nature, and proper technique matters a lot if you are competing at the highest levels. But you do not see coaches trying to dictate what each player will do on every conceivable situation. Even in extremely structured sports, like football, the coach dictate a general strategy and changes tactics according to the dynamics of the game, but each individual player needs to apply a minimum of discretionary judgment to react to situations that arise mid-play.
A coach that tried to move his players like puppets would be crushed by the competition. An army with such general and soldiers would be crushed in a more literal way. Why is it not the case with software companies?
Crappy teams and bad management creates management problems, not tools.
JIRA is fine. So far as "enterprise" tools go I'd actually say it's quite decent. Good teams need ways to collaborate and communicate on projects and JIRA has a lot of good features to do that as do other options out there. However, at the end of the day good tools don't make up for crappy teams... and honestly good teams will find their way to work with/around bad tools. However if you have crapy teams and crapy management then you're basically just screwed... but you know someone will decide to do another pointless re-org or something dumb to try and solve the problems.
This blog elicited a chuckle. My employer recently mandated JIRA for all teams, even those teams which have been using other agile tools for years. No good explanation was given.
Ditto... it was a way for them to standardize reports from various teams veiled as a cost cutting initiative. Since they are unwilling to pay for anything (read plugins), our JIRA boards are shells of the tools we were using and paying for team by team.
Centrally mandating the use of a tool is not a management problem.
When you need to try and account for where your time is going, there are two ways - have everyone use a slightly crappy tool that they loathe (mostly for its purpose), or have some sort of process in place that is less efficient with everyone's time.
> We must ensure JIRA usage is identical across teams, in order to ensure velocity parity
In real talk:
> We want to standardize our time accounting across teams to ensure everyone is moving as fast as possible.
How diabolical.
The bemoaning of having to do basic project communication is a symptom of a novice professional.
> I have no beef with JIRA per se, but its the one we come across the most. > Here’s what a colleague said, just this morning about JIRA: >> We must ensure JIRA usage is identical across teams, in order to ensure velocity parity
> So, clearly this is no fault of JIRA — I (as I’m sure you) have seen it used many a time successfully, but all to often, it is used (and abused) as a top down management tool, mandated from the centre.
Uh... then don't work for company with shitty management... This has absolutely nothing to do with JIRA. You could find and replace 's/JIRA/Rally/' and while the article would still be wrong it would make as much sense. There is nothing inherently wrong with JIRA itself. If you have shit management then you have shit management and no tool is going to help/hurt that really...