3 ms·

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

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
  - musicale 2y ago
    Always amusing when the same insurance companies that delay for months while they come up with new reasons not to pay a claim threaten to cancel your policy if your premium is paid a day late. I suppose it's the same with software features.
- nextos 2y ago
  What would you recommend instead of Basecamp?
  - solardev 2y ago
    I personally really like Linear or Airtable. But most of the time it's not up to me anyway. If you can win any concessions over overbearing dogmatic Agile, that's already a pretty big victory, IMO. The tooling is secondary if you like your team and managers and work can proceed without anyone getting frustrated or too annoyed. It's a cultural thing. I'm not a huge fan of Basecamp, but it's not the worst either, and it makes the rest of the team happy. That makes me enjoy working with them, and it all works out in the end with very little stress or panicking. My last job had some sort of half-configured, mostly broken Jira put together by some powerful being who's long since left this plane of existence, abandoning his creation to his unloved mortal children. No one really knew why the columns had the particular workflow limitations they did, what our points were supposed to represent, how our work tied into other teams' work, how their points worked, etc. We didn't even have compatible Atlassian instances, so even though we all used Jira and Confluence, nobody could see anyone else's. I tried to point out some of those problems in a detailed report, but they told me to hide it so it doesn't embarrass them, and then hired an Agile consultant to double down on everything that was broken. I quit two weeks later and am much happier now because of it (much poorer too though, lol... can't have it all, I guess).
- CRConrad 2y ago
  > ...my current job uses Shape Up and Basecamp (https://basecamp.com/shapeup https://basecamp.com/shapeup) instead of Agile or a Kanban... What, is "Agile" percieved to be so tightly bound-up in some particular methodologies (or trademarks?) nowadays that your seemingly quite agile methods and tools aren't part of it? AFAICS Basecamp[1] -- and certainly Kanban! -- is agile. --- [1]: If I recall correctly what that is.
  - solardev 2y ago
    It's not so much Basecamp, but Agile mixed with Scrum and then enforced very strictly that's the issue. Some companies will take the Agile philosophy (originally simple and short) and pervert it into a waterfall by adding extreme Scrum ceremonies like endless points poker (https://www.atlassian.com/blog/platform/scrum-poker-for-agile-projects https://www.atlassian.com/blog/platform/scrum-poker-for-agil...) and detailed retrospectives (https://echometerapp.com/en/retrospective-tools-online/ https://echometerapp.com/en/retrospective-tools-online/), sometimes with the help of outside Agile coaches. Unfortunately, this corrupt version of it seems way more popular than the original Agile philosophy (which, yes, a simple Kanban can do). Scrumfall warps the whole philosophy from small chunks of iterative autonomous work into quarters of pre-planned top down work, just broken down into absurd things like fibonnaci numbers or t-shirt sizes instead of hours. It makes middle management look organized at the expense of decreasing worker productivity, basically by hiding micromanagement behind tooling. Uses a lot of ceremony and jargon to do a waterfall by another name. ---------- Typically that's done in other tools, like Jira plus outside ceremony software (yes, there is an entire SaaS niche for these ceremonies). Basecamp doesn't do that, to its credit. It is its own workflow (Shape Up). I dislike it for other reasons, but less so than Scrumfall. Basecamp the software is slow and doesn't format code very well, and is pretty disorganized (multiple projects, kanban boards, chats, message boards, to-dos, check-ins etc lead to many sources of truth, and it's impossible to find anything even a week later). Shape Up the methodology is too vague and abstract IMO and has very slow iterations and lacks a focus on customer needs and wishes. But both are still a huge improvement over Scrumfall.
    - CRConrad 2y ago

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
- musicale 2y ago
  Always amusing when the same insurance companies that delay for months while they come up with new reasons not to pay a claim threaten to cancel your policy if your premium is paid a day late. I suppose it's the same with software features.
nextos 2y ago
What would you recommend instead of Basecamp?
- solardev 2y ago
  I personally really like Linear or Airtable. But most of the time it's not up to me anyway. If you can win any concessions over overbearing dogmatic Agile, that's already a pretty big victory, IMO. The tooling is secondary if you like your team and managers and work can proceed without anyone getting frustrated or too annoyed. It's a cultural thing. I'm not a huge fan of Basecamp, but it's not the worst either, and it makes the rest of the team happy. That makes me enjoy working with them, and it all works out in the end with very little stress or panicking. My last job had some sort of half-configured, mostly broken Jira put together by some powerful being who's long since left this plane of existence, abandoning his creation to his unloved mortal children. No one really knew why the columns had the particular workflow limitations they did, what our points were supposed to represent, how our work tied into other teams' work, how their points worked, etc. We didn't even have compatible Atlassian instances, so even though we all used Jira and Confluence, nobody could see anyone else's. I tried to point out some of those problems in a detailed report, but they told me to hide it so it doesn't embarrass them, and then hired an Agile consultant to double down on everything that was broken. I quit two weeks later and am much happier now because of it (much poorer too though, lol... can't have it all, I guess).
CRConrad 2y ago
> ...my current job uses Shape Up and Basecamp (https://basecamp.com/shapeup https://basecamp.com/shapeup) instead of Agile or a Kanban... What, is "Agile" percieved to be so tightly bound-up in some particular methodologies (or trademarks?) nowadays that your seemingly quite agile methods and tools aren't part of it? AFAICS Basecamp[1] -- and certainly Kanban! -- is agile. --- [1]: If I recall correctly what that is.
- solardev 2y ago
  It's not so much Basecamp, but Agile mixed with Scrum and then enforced very strictly that's the issue. Some companies will take the Agile philosophy (originally simple and short) and pervert it into a waterfall by adding extreme Scrum ceremonies like endless points poker (https://www.atlassian.com/blog/platform/scrum-poker-for-agile-projects https://www.atlassian.com/blog/platform/scrum-poker-for-agil...) and detailed retrospectives (https://echometerapp.com/en/retrospective-tools-online/ https://echometerapp.com/en/retrospective-tools-online/), sometimes with the help of outside Agile coaches. Unfortunately, this corrupt version of it seems way more popular than the original Agile philosophy (which, yes, a simple Kanban can do). Scrumfall warps the whole philosophy from small chunks of iterative autonomous work into quarters of pre-planned top down work, just broken down into absurd things like fibonnaci numbers or t-shirt sizes instead of hours. It makes middle management look organized at the expense of decreasing worker productivity, basically by hiding micromanagement behind tooling. Uses a lot of ceremony and jargon to do a waterfall by another name. ---------- Typically that's done in other tools, like Jira plus outside ceremony software (yes, there is an entire SaaS niche for these ceremonies). Basecamp doesn't do that, to its credit. It is its own workflow (Shape Up). I dislike it for other reasons, but less so than Scrumfall. Basecamp the software is slow and doesn't format code very well, and is pretty disorganized (multiple projects, kanban boards, chats, message boards, to-dos, check-ins etc lead to many sources of truth, and it's impossible to find anything even a week later). Shape Up the methodology is too vague and abstract IMO and has very slow iterations and lacks a focus on customer needs and wishes. But both are still a huge improvement over Scrumfall.
  - CRConrad 2y ago