Comment by matt_s
20 hours ago
I bet there are bunch of ways to organize work in Basecamp, just like any other tool, and its just how your organization has it setup that bothers you. Most of the issues you describe aren't software issues, they are issues with how the people are organized around the work.
Does Basecamp force everything to be 6 week projects? I would think it should be configurable, I can't imagine every single customer of theirs is ritually following the same exact process outlined in Shape Up. From reading their books, their approach is more about what works for them and sharing that in case it might also work for others and that there are other ways to think about doing work. I wouldn't take anyone's process book as the holy grail that must be followed to the letter. It sounds like your management has done that though and usually that will not work out no matter what process or tool is being used.
Backlogs are a lie. Having a giant list of things people wanted to do at one point but they never saw the light of day isn't super helpful for software development. It is a good way to appease people by telling them you're tracking it, might as well be in the waste bin though. If you capture a feature request and put it in the backlog, then look at it 3 or 6 months later, its very possible that feature is no longer relevant, the software underlying that feature has already changed with other work, etc. So capturing a lot of detail on something that is a "someday, maybe" type of request is pointless. Maybe a wiki doc of ideas is better.
Bugs are a different story - customer issues/bugs reported should be captured if they are relevant. Urgent critical bugs should be able to be created in any work tracking system and be worked, again this smells more like the people organizing the work and defining your processes have things kinda borked up.
> I bet there are bunch of ways to organize work in Basecamp [...] Most of the issues you describe aren't software issues, they are issues with how the people are organized around the work.
I think that's fair, but to some extent, the tooling will naturally lend itself towards some process or another, and thereby encourage (not force) people to do things a certain way. It's possible to use Basecamp with only one project and the Kanban board, for example, and not use the chat or forum features. But that's just not really how it's made to work.
It is more the combination of Basecamp + Shape Up that I don't like, especially the idea that the "backlog is a lie". Honestly, that's one of the very few things I miss about Agile. Not so much the grooming sessions, the t-shirt sizes, or any of that crap, but just having a single, organized place where you can put ideas in cold storage and refer back to them time and time again.
Even with an ungroomed backlog, it's very easy to say "this feature request/bug is very similar to ticket 12345; let's merge them". And then over time it naturally accumulates more and more relevance and hopefully eventually becomes worth doing, and you can immediately justify that from all the connected tickets and concerns. It isn't so much the level of detail that's useful, but having a single reference acting as a single source of truth for a given issue.
Without a backlog, using just a document (or in our case, often nothing at all), the same ideas keep popping up, but there is nothing to refer them against. A single bullet point in some ideas doc isn't easy to cross-reference by hyperlink, either for other devs, customers, or onboarding new employees. You go from 'we have a source of truth with too much junk in it" to "now there's no source of truth anymore, just a bunch of vague ideas floating around in various documents and in people's heads". IMHO that is not an upgrade, not even a sidegrade, just a plain downgrade. It's exchanging "a large amount of tickets organized in a single place" (which is difficult to get through, yes) for "a large amount of ideas without any organization at all" (which is even harder to work with).
The lack of a backlog doesn't magically make lower-priority issues disappear. It just makes them harder to track over time, such that you end up having to reexamine them and re-triage them and re-evaluate and re-plan them every time the same thing comes up. With a single ticket to reference in a backlog, each incremental update takes a few minutes (oh, this is what's changed since 6 mos ago). Ideally you'd update the original description too (I always do that, but granted not everyone would). If you don't even have that ticket to reference, you're just starting from scratch every time and it's frankly exhausting.
The backlog doesn't have to be something super complex and time-consuming. It can just be one column in the Kanban. (I love Airtable and would love to try Linear for this). Maybe even a wiki, as you suggested, although I think that'd just become yet another source of truth vs an integrated backlog... the way that Jira and Confluence already often fight each other for dominance.
-----
That said, if you (or someone you know) HAS had positive experiences working with Basecamp & Shape Up using some different kinds of organization... I'd love to hear their thoughts! If there's anything I can suggest to my org to make things easier to work with, it's worth a shot.
(And FWIW, I don't know this for sure, but I think many of the other devs on my team DO like Basecamp. I may just be an outlier... haven't surveyed them. Maybe just how my brain works? I dunno.)