6 ms·

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. Som

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.

tpurves 2y ago
Kanban as mentioned by this commenter and others are great processes that do maximize productivity, flexibility, and often developer happiness. I love Kanban for the initial cycles of a project and as long as you can keep it going. The weakness of Kanban tends to be in predictability of future delivery, which becomes a problem when external commitments or obligations pile up, or as orgs grow and lot of cross-team dependencies emerge. So you start to lay on more structured agile process so you can better forecast future delivery and protect your team from tendencies to miss-set expectations on scope or deadlines, which can have big impacts on customer relationships or in high level company strategy decisions. So you might consciously start to trade-off in your process design, some efficiency and bureaucracy costs at the team level in favor of making better choices and efficiency at the org level.
animal_spirits 2y 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 2y 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 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 2y 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
AndrewKemendo 2y 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.
xs83 2y ago
I've been on both sides of the software cycle as a stream lead and as a developer and ultimately I think this is it. Agile gets bastardised as soon as specific reporting structures and deadlines come into place "What do we need to plan for this increment?" etc A team with a good work ethic and some milestone goals to go to and a "Take from the top" mentality, Kanban is perfect for what needs to be done. Can't take from the top "because of reasons"? Thats a conversation with the people that particular problem involves and things are re-prioritised. I'll never understand removing a whole day of productivity for ceremonies to plan being more productive. Async standups via Slack using Geekbot are absolutely fine, A daily simple async retro for teams on a different timezone also help massively for synchronisation, discipline to update tickets with progress and a push regularly mentality all helps with the sync problem if across timezones!
winternett 2y ago
Most of these methodologies came from the car making industry... I think if we realize that and compare making cars to the process of managing software, it's easy to adjust and manage aspects of efficiency & output.... The problem is that humans (the actual devs and process managers) are not often accounted for in the process now, as robots have taken over most of the aspects of car making, so while Agile may look ideal in many cases, the output if often not predictable when staff can quit, rebel and burn the factory down, join unions and demand more pay, or take vacations (for example).
- aiaiaiaiaiai 2y ago
  Making software cannot be repetitive and is always novel. Commands like cp, scp, cat, git clone... made the repetition part redundant eons ago. The first magnetic tape did. Cloning data is so low cost. Cloning a car is high cost. It makes sense to tame the complexity and think waterfall vs. this or that but we aint building cars or houses.

tpurves 2y ago

Kanban as mentioned by this commenter and others are great processes that do maximize productivity, flexibility, and often developer happiness. I love Kanban for the initial cycles of a project and as long as you can keep it going. The weakness of Kanban tends to be in predictability of future delivery, which becomes a problem when external commitments or obligations pile up, or as orgs grow and lot of cross-team dependencies emerge. So you start to lay on more structured agile process so you can better forecast future delivery and protect your team from tendencies to miss-set expectations on scope or deadlines, which can have big impacts on customer relationships or in high level company strategy decisions. So you might consciously start to trade-off in your process design, some efficiency and bureaucracy costs at the team level in favor of making better choices and efficiency at the org level.

animal_spirits 2y 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 2y 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 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 2y 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

AndrewKemendo 2y 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.

xs83 2y ago

I've been on both sides of the software cycle as a stream lead and as a developer and ultimately I think this is it. Agile gets bastardised as soon as specific reporting structures and deadlines come into place "What do we need to plan for this increment?" etc A team with a good work ethic and some milestone goals to go to and a "Take from the top" mentality, Kanban is perfect for what needs to be done. Can't take from the top "because of reasons"? Thats a conversation with the people that particular problem involves and things are re-prioritised. I'll never understand removing a whole day of productivity for ceremonies to plan being more productive. Async standups via Slack using Geekbot are absolutely fine, A daily simple async retro for teams on a different timezone also help massively for synchronisation, discipline to update tickets with progress and a push regularly mentality all helps with the sync problem if across timezones!

winternett 2y ago

Most of these methodologies came from the car making industry... I think if we realize that and compare making cars to the process of managing software, it's easy to adjust and manage aspects of efficiency & output.... The problem is that humans (the actual devs and process managers) are not often accounted for in the process now, as robots have taken over most of the aspects of car making, so while Agile may look ideal in many cases, the output if often not predictable when staff can quit, rebel and burn the factory down, join unions and demand more pay, or take vacations (for example).

aiaiaiaiaiai 2y ago
Making software cannot be repetitive and is always novel. Commands like cp, scp, cat, git clone... made the repetition part redundant eons ago. The first magnetic tape did. Cloning data is so low cost. Cloning a car is high cost. It makes sense to tame the complexity and think waterfall vs. this or that but we aint building cars or houses.