Hacker News Reader

Comment by lmm | Hacker News Reader

> 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"?

View on HN

> 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?

Reply on news.ycombinator.com