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?
> 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
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.
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.
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-agil...) and detailed retrospectives (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.
Yeah, I agree on pretty much all of that. My point was actually a much smaller one, about just part of it:
> It's not so much Basecamp, but Agile mixed with Scrum and then enforced very strictly that's the issue.
Namely, how the scrumsters and other hucksters have taken this "agile mixed with Scrum" and called that Agile-with-a-capital-A. Or, as you seem to be saying, taken Agile-with-a-capital-A and mixed it up with their own shit and saying that that's The Real Thing[TM]. Is there even such a thing as Agile-with-a-capital-A? I wonder, kind of doubt it... The whole idea seems about contemporaneous with the beginnings of the corruption of the original concept, so I suspect it's theirs.
Either way: Don't let them get away with it! Don't even talk about "Agile", with a capital A, because that implies there is a hard-and-fast definition for someone to usurp. And if people think there is such a thing, some such huckster will inevitably usurp it.
I think that battle is lost, unfortunately :( In every single team I've ever been a part of, Agile is used exclusively in the Scrumfall sense (I didn't come up with that second term either; it's just what the post-Agile blogosphere calls it).
When I point out that, done this way, it goes against the entire philosophy of the original Agile Manifesto... I just get shrugs. People don't care what it used to mean; when they say it now, they mean the points and ceremonies and masters and the whole ugly shebang. It's not a battle I have the energy to fight.
When a workflow isn't like that, but is just lean & simple on its own, they don't go out of their way to call it Agile or agile, uppercase or lowercase. It's just "a simple workflow" or something like that, or else some explicit other workflow (like Shape Up). I think a lot of folks have been burnt out by Scrumfall and try to practice alternatives.
I've made a point to start asking potential employers how they handle project management. If they say Agile of any sort, I'll assume the worst and just walk away...
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).
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?