solardev
11 hours ago
At the small teams I've worked in, having just a Kanban board as the single source of truth was both more useful and way less stressful than dogmatic Agile. Something like Linear, Github Projects, Airtable, Trello, or (if you must) Jira.
It minimizes the time spent on unnecessary bureaucracy and ceremony, while still giving you the transparency and flexibility behind Agile. Supervisors and such can look at the board and see what the team is working on and what stage they're at. And when emergency things inevitably come up, that's when you pause what you're working on, temporarily put that in the "on hold" column, and work on whatever the new critical priority is before going back to your original work (usually) or else pivoting altogether (which often happens in more top-down orgs).
A Kanban is by nature not prescriptive, but after-the-fact descriptive. It respects people over processes – a fundamental part of the Agile philosophy that too often gets buried in dogma – by respecting each worker's autonomy while also giving the team as a whole flexibility. If you need to change things up, you just send a few messages or do a huddle instead of spending half the day arguing about points and then arguing about them again in the 2-hour retrospective.
In the most dysfunctional orgs I've been a part of, it wasn't really Agile anything or any particular tool that was the problem, it was that they were so middle-management heavy that most of the dev time was spent managing up instead of coding. That isn't a something tooling can in and of itself solve, but I've found that the heaviness of the tooling is often a good proxy for the dysfunction of the management layers. In that case I'd fight to simplify things and make work more efficient, or ask for a transfer to a more efficient team, or just leave the org altogether. When there's that many head chefs in the kitchen, every minor feature becomes a political battleground and no real work will get done, no matter your process.
AndrewKemendo
an hour ago
This is where I’ve landed after doing it a long time.
If you need to get more granular than an open Kanban and are time bound, it’s just Kanban that refreshes some interval (2 weeks etc…) with a triaged backlog
Realistically the basic winning set up is:
0: Know what you’re building and why 1. Feature/bug funnel 2. Triage to: Next iteration Kanban, prioritized backlog or deleted as unnecessary in forecast window 3. Deliver with unit testing based on Prioritized Time bound Kanban 4. Move Prioritized backlog into next iteration (go too far ahead at your own risk) 5. cut line: return task to step 2
Every step is critical here actually and breaks without each.
animal_spirits
11 hours ago
This is essentially how my team works, however, we do two weeks sprints so that we can package all of our code and deploy it to our customer machines once every two weeks. It works better when we have more lenient managers who are comfortable with work spilling over if necessary, but I’ve had some managers that make that a little more uncomfortable.
solardev
10 hours ago
Why not just ship what's ready at the end of any particular cycle, and spill over whatever's not? Customers don't care about your 2-week cycles, and rather than rushing something out the door, they can just wait a little longer?
I think there will always be some tension between developers who need some undefined and undefinable amount of time to produce work, and managers who need to protect timelines for the business's (and other teams') sake, and the only real solution that I've seen is to underpromise work on purpose, every time.
Maybe you lose a little productivity only aiming for 70%-80% bandwidth to start with, but that's way better than aiming for 100% and then not having any bandwidth left to deal with the inevitable bugs and sudden issues and help requests from other teams. And then suddenly it's the end of a cycle and everything blows up. A steady, slow pace helps prevent that terrible crunch at the end and makes work easier for all your employees and your customers don't get saddled with an explosion of bugs with every release.
---------------
Separately from all that, my current job uses Shape Up and Basecamp (https://basecamp.com/shapeup) instead of Agile or a Kanban, which is a different enough methodology that it's worth considering if you've never looked at it.
Personally I don't really like it that much and wouldn't recommend it (especially Basecamp, which is way over-complicated and slow and not very code-friendly), but the other devs seem to really love it. Perhaps it's worth a look and you can decide for yourself?
animal_spirits
8 hours ago
> Why not just ship what's ready at the end of any particular cycle, and spill over whatever's not?
We do, but many times customers are paying many thousands of dollars for feature requests and have particular deadlines they want it by. Especially in our industry where there are a handful of competitors fighting to get huge contracts. We sell to insurance companies, so there is a lot of legacy software being replaced.
> and the only real solution that I've seen is to underpromise work on purpose, every time
Yep, we've become much better at underpromising in order to protect ourselves
nextos
6 hours ago
What would you recommend instead of Basecamp?