Hacker News Reader

Comment by lmm | Hacker News Reader

Wow. I hate JIRA but this article gets it completely backwards. Having small-scale tickets that you actually finish is the very essence of agile - limiting work in progress, defining "what done looks like" in a customer-facing way for tasks that each last at most two weeks. Ignoring the "wider vision" is the best way to produce software that actually solves people's problems instead of beautiful n-tier architecture that doesn't do anything anyone wanted.

JIRA is heavy and slow - it's model of limited transitions is fundamentally flawed, encouraging micromanagement and making mistakes hard to undo. But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).

View on HN

> Having small-scale tickets that you actually finish is the very essence of agile

Bollocks.

The "highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Not tickets, small or otherwise. Not tasks. It has nothing to do with two-weeks.

> Ignoring the "wider vision" is the best way to produce software that actually solves people's problems

I have no idea what you could possibly mean by this.

Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software, and that's assuming they get done at all.

> But a lightweight board that you push tickets through - the famous "kanban" - is a great way to develop software (I've had a lot of success with Trello, though I fear it's only a matter of time before Atlassian bloats it into JIRAness).

Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.

https://agilemanifesto.org/principles.html

The problem with Agile is that no one is doing True Agile™, because no one can agree on what True Agile™ is.

Dave Thomas himself declared Agile dead a few years ago, but offers up what I think is a better definition

https://www.youtube.com/watch?v=a-BOSpxYJ9M

Well, that's because there are so many false prophets.

I like Jira. It's terrible, of course, but way better than using nothing. Tech Crunch is mainly criticizing how "Agile" development is commonly used, to micromanage and give a false sense of grasp of the scope of a project for management. Micromanagement without the responsibilities coming with micromanagement (providing nice specifications, doing follow ups, taking responsibility for failures, etc) make me miss the waterfall model ...

Do not try to do True Agile, only try to realize the truth. There is no True Agile.

To me, Agile is really a set of principles to help you decide what to focus on (e.g people over processes). The different methodologies (scrum, kanban, etc) are just frameworks to help you build the best dev process for your team while trying to keep the agile principles front and center.

In reality, all kinds of factors get in the way of True Agile - experience of devs, team dynamics, company incentive structure, management expectations, management’s management expectations, how the company handles failure and the subsequent ownership vs finger pointing, etc. The actual implementation of Agile should be different for each organization because the environment in which they operate in is different. With that said, there are certain core principles and practices that are very beneficial across the board and consistency across teams within an organization certainly helps.

True Agile says “people over processes” meaning it’s different for everyone.

JIRA and Scrum are great ways to facilitate agile development but it's not bidirectional. I usually push rigid Scrum on teams if I think they lack discipline or experience. Follow the textbook until you understand why. When I'm working with smart veteran devs who know exactly why and how agile works, we can afford to be more freewheeling.

I think agile is fundamentally simple. The essence is the continual improvement. How that translates into a working process (like when do I write tests and who updated the docs) are going to vary project to project.

> Not tickets, small or otherwise. Not tasks. It has nothing to do with two-weeks.

Just what do you think "early and continuous delivery of valuable software" looks like in practice then?

> Every time I've ever seen a modular development that isolates developers from the business (or from each other), I've seen brittle software

Completely agreed. I've found any "vision of the project as a whole" is exactly where that isolation tends to happen: once this "skeleton of the city" is laid out, business input gets cut out because The Plan has already been agreed.

> Listen, if software helps you, then great, but if your whole life is "pushing tickets", you're not doing Agile. It doesn't matter if you're using Jira or Jello.

Nonsense. Again, how better to achieve "early and continuous delivery of valuable software"?

> how better to achieve "early and continuous delivery of valuable software"?

By building an application and putting it in the hands of the business as often as possible.

Thirty years ago I used a whiteboard.

I never needed ticketing software to build software or to ship software.

The only time I ever used ticketing software (from the contributor side of the fence) is when the business I was working for wanted it, and the only thing they ever did with it was track my time. Good for them.

Now when I'm on the management-side of the fence, I still don't really like ticketing software. I use Jira because the rest of their business uses Jira, and they want accurate reporting for R&D tax credits and doing KPI-based bonus remittal, and they've built reports and scripts on top of Jira. Some of my developers like to use the tickets themselves, and some prefer to let my assistant do the ticket busywork.

My takeaway from this comment: you have an assistant?!!

Someone needs to create a virtual assistant startup that focuses on the JIRA management niche.

I'd buy the developer package.

How would you physically do it?

Do you give the VA their own JIRA login? Or can we make a browser extension that lets the VA use yours (or mine)?

(My contact details are in my HN profile if you want to discuss)

> By building an application and putting it in the hands of the business as often as possible.

Just putting the application in the hands of the business is not enough, you need to ensure that you're actually delivering value to the business. You need pieces of functionality that you know the business values (and where both sides understand what the valuable thing is) - i.e. tickets.

> Thirty years ago I used a whiteboard.

> I never needed ticketing software to build software or to ship software.

I'm sure I could keep it all in my head, but I'd rather spend that mental capacity on more important things. That you found a whiteboard useful says that tooling can be helpful - and Trello can be more convenient than a physical whiteboard.

> Just putting the application in the hands of the business is not enough

Yes, it really is. There is so much software that has been built without a ticket system. If you need examples, just ask!

Tickets can be a proxy for business value, in a way that a checkbook is a proxy for money, but it’s not the checkbook that pays salaries: Software is built in the brain.

>it’s not the checkbook that pays salaries

Doesn't the checkbook of a business literally pay salaries? I'm unclear as to what you're arguing here.

> Doesn't the checkbook of a business literally pay salaries?

Hint: Some businesses don't even use checkbooks.

> I'm unclear as to what you're arguing here.

Is it really unclear?

Having small-scale tickets that you actually finish is the very essence of agile

This I disagree with. "lmm" seems to think that tickets are either "the very essence of agile" or perhaps even essential to "deliver value to the business."

I can believe you've built valuable software without a "ticket system", but not without tickets, whether you called them that or not. You need pieces of functionality that get agreed between the business and the developer. And while it's possible to keep them in both your heads, it's easier and more reliable to record them in writing.

> business input gets cut out because The Plan has already been agreed

But is this because the developers want that, or because management has carved in stone The Schedule, based on The Plan, and the only way for dev to stay on that schedule is to reject updates?

I love how much this comment is a perfect example of developers thinking about nothing but software development. As a sysadmin, I've custom written ticketing software, and used just about all of them, and the thing is Jira really fullfils a role in companies that most of the other ones don't, and I'm not even talking about software development! It's far from perfect, that's for sure, which is why I use jira from emacs. So many people here seem to think every business is a SV software startup and not just some regular old business trying to get shit done and it has repeatedly been a problem I've seen and I'm sure it's the cause many a miscommunication.

While I've seen non-software teams use Jira before as well, I don't think it's unreasonable to talk about Jira as a tool designed for software development; from their homepage:

"The #1 software development tool used by agile teams"

and

"The best software teams ship early and often."

and

"Development workflow: Jira Software automatically updates issues and transitions work when code is committed in Bitbucket."

and

"Continuous integration: Power your CI with Bamboo and monitor build statuses without ever leaving Jira Software."

(That last sentence is nightmarish.)

Well yes. I do develop software, but I've always thought of myself as a sysadmin who programs (AS21863 for over a decade) instead of a developer who "ops". These days I'm also an executive (of an LSE listed company). I do these jobs differently, even if I use (some of) the same tools for each.

I think a lot of people believe that it's their tools that make them able and forget it's their brains that use and make the tools.

I also think that anyone who thinks using a particular tool is essential (as opposed to meritorious) needs to get their head examined.

Do you have any details about your emacs/jira workflow?

Jira also has the least consistent UX of any SaaS product I've used (Skype may be a close second).

I sort of agree with you but I love JIRA. Tbe problem really lies in the way people use it. It’s just another tool, and it can be used any way your organization deems necessary. Unfortunately, most orgs tend to make a religion out of it, and the Agile process becomes bastardized by abusing JIRA. Just by observation, I have concluded that management loves JIRA precisely because it allows them to micromanage (“hey Temporallobe, how are you coming with story XY-5678? I see it’s been in-progress for 3 days...”). Again, that’s not JIRA’s fault, but to use an Agile term, it’s an “enabler”.

Tools drive the way they get used, and JIRA naturally guides teams into micromanagement. Have you tried a more lightweight cards-on-board tool (like Trello)?

I agree with you about Trello, but even better than that is paper-cards on a wall.

Trello adds unlimited wall space and a distributed wall. If you don't have lots of remote workers, and the wall is big enough, then use it. There is something wonderfully tactile about chatting in front of a real kanban wall when working out priorities. At the next checkpoint/sprint meeting, you can physically add cards to your backlog. Physically push things up the priority list. I love it!

I like 5×3 index cards better than post-it notes..

The problem with trello is linking tickets intelligently is hard.

The concept of epic/subtasks is missing. So if a ticket becomes to big, and you want to keep the history while breaking it up, requires a boat load of copy/paste.

Also, there is a trend to have a physical board with tickets, as well as a trello board. This was fashionable amongst the scrum masters at previous large employer. It was universally hates as we had to spend loads of time playing with physical cards, then try and copy the state into the ticketing system. Its was annoying and a massive waste of time for everyone.

Especially as it didn't encourage people to write the work they've done on the ticket, to allow it to be taken up by someone new.

> Also, there is a trend to have a physical board with tickets, as well as a trello board.

Oh no! This sounds like a horrible idea! Two sources of truth, everybody trying to avoid the work of syncing them. Eek.

> The problem with trello is linking tickets intelligently is hard.

One way is to break any sizeable task onto it's own board. Just note on the card that it has been moved to a board of it's own. There is a logical team>board structure for this. Then you have a master board with the main building blocks on it, and then sub boards with tasks/stories on them. It is no panacea, but it can work

> One way is to break any sizeable task onto it's own board. Just note on the card that it has been moved to a board of it's own. There is a logical team>board structure for this. Then you have a master board with the main building blocks on it, and then sub boards with tasks/stories on them. It is no panacea, but it can work

We've experimented with this type of thing in my company. In practice, we found that having multiple boards for a single project is just a bit too much to keep track of.

I could see this working if Trello made it easy to quickly move between boards. This could be something as simple as a breadcrumb style path: Grandparent Board > Parent Board > Child Board, or something to that effect.

Or maybe that would overcomplicate Trello, I'm not sure.

Cool, I work remotely, can you point a webcam at your wall of cards please? Also remember to record your tactile chats in front of the wall so the rest of the remote team can hear them.

What I see in this article is a point that there's a discrepancy between goals and tasks needed to achieve these goals. If you're using JIRA for both planning features and measuring work hours spent (which many organizations are) then this brings some trouble - in an agile sprint, it makes all sense to plan that you'll do features A, B and C this week and get to D and E next week; however, it may be that by the end of the week you've spent 4 hours each to finish A, B and C and 20 hours on an infrastructure task (that's mostly done but not yet) that's needed not only for A and C but also for the next week's tasks.

The detail level and task breakdown which is appropriate for planning which features you'll prioritize and do for a sprint may not be a good task breakdown for actually assigning sub-tasks for people, looking at their progress/status during a sprint, and mapping particular commits or hours worked to them. JIRA common practices sort of force those things to be the same, which may be considered harmful.

There's a middle ground between shipping a bunch of features and beautiful architecture that does nothing. At the end of the day, spending heavy up front time on designing great, flexible architecture lets you iterate much more quickly to ship the features people want.

> At the end of the day, spending heavy up front time on designing great, flexible architecture lets you iterate much more quickly to ship the features people want.

Not my experience. The most important way to get flexible architecture is simplicity - not having things you don't need. More often than not, architecture designed for some kind of flexibility up front turns out to impede flexibility in a different direction (which was actually what was needed) where a more naive design would have been fine.

My favourite "agile Jira" is https://clubhouse.io/

What do you like and/or hate about it? My company is considering migrating away from Trello and I'd like to arm myself with as much information as possible on this topic.

It's basically a simplified Jira, with a strong focus on software development support and just the right amount of customizability.

Reply on news.ycombinator.com