Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What's the Alternative to Agile?
33 points by animal_spirits 73 days ago | hide | past | favorite | 37 comments
Hello HN, I often see arguments about the agile process on here, most recently on this post: https://news.ycombinator.com/item?id=41612154

My question is this; what alternatives are there to agile? I know there is the waterfall method, but from what I understand we as an industry moved to agile because of the weakness of waterfall in the internet era. What other alternatives do you suggest? Where should we look for improvements?




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.


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!


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.


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


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.


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.


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.


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.

I suppose it's the same with software features.


> ...my current job uses Shape Up and Basecamp (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.


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


What would you recommend instead of Basecamp?


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


An alternative to Agile is Deep Work, which focuses on uninterrupted time for focused problem-solving instead of frequent meetings and updates. While Agile promotes quick iterations, Deep Work emphasizes sustained concentration, allowing teams to tackle complex tasks without distractions. It’s not a framework, but a focus-oriented approach that could complement or enhance existing workflows.


this is heaven for ADHD folks


Agile is a very wide umbrella and most often what people are complaining about is when they join a team that is using SCRUM in a rigid way without actually thinking about the process and how better tailor it to the team.

If you look at all of the processes, tools and ceremonies available to ou from various agile methodologies - you can tailor things to your liking.

I was in teams where scrum actually worked, up to and including the story-pointing and backlog-requiment giving us accurate estimates of how long features will take to develop.

And then we had more ad-hoc/timely work for some quarters and we dropped most of the plan/sprint/refine structure in favor of more simple kanban board.


Shapeup https://basecamp.com/shapeup


Thanks for sharing. I never heard/knew of this one.


1. A classic book is The Mythical Man-Month and it discusses a surgical team approach that I think is interesting where there are lead surgeons and the rest of the team is there to support them.

2. Programmer Anarchy by Fred George on YouTube is an interesting idea.


MMM is a good book, but I like to suggest Weinberg's The Psychology of Computer Programming as another contemporary (to it) take that discusses both how to examine what's happening in teams (effective or not) and what was observed in some teams (effective and not). Like MMM, it received an update later on. Weinberg left his original text essentially intact (I think light changes to address errors in the printing, not changes to what was written though) and added commentary to each chapter instead of editorializing them directly.


Read the agile manifesto and tell me you don’t want to do those things…


Well, there is quite some difference between what the agile manifesto describes and what the 5000-page Agile Handbook (TM) of some international consulting firm describes.


Ignore those handbooks they’re selling you snake oil.

The original agile manifesto though is still valid. Guiding principles is all you need


Dave Thomas, one of the creators of the agile manifesto, has a talk where he expresses his disappointment with consultants twisting the manifesto into a cult-like industry.

He calls this the agile industrial complex and says that anyone using agile with capital A is not referring to the manifesto but the industry and are selling you that.

Agile is Dead - https://www.youtube.com/watch?v=a-BOSpxYJ9M


Yeah but I’m looking for proven alternatives. No one says agile is perfect


> No one says agile is perfect

Read the agile manifesto and tell me what you want to do that isn't in there.


Well, for me it isn't? I don't do project work, I am a maintainer at heart. If I am doing my job well, anybody who I think of as my customer will be happy if they need to interact with me as little as possible, because my well documented processes and tools are on-point :D


The process is derived from PDCA (plan, do, check, act), which you might find more freeing.

The beauty of PDCA is that it is an adaptive framework. Meaning how it’s applied to my team will be different than your team. That’s a healthy development that relates to the fact that different people will work together differently. (side note: agile is often used as a synonym with pdca and it can confuse thing bc Agile tm is what a lot of people have bad experiences with)

i wrote a bit about my experience using agile: https://hedgerider.substack.com/p/agile-for-anarchists


The first line from the agile manifesto: Individuals and interactions over processes and tools

It's all about communication and hiring. I've found agile to ensure the bottom 10% participate in important discussions (stand-ups, refinement meetings, feedback on process in retros).

If you hire the right people that take initiative and over-communicate, a lot of process suddenly seems unnecessary.


I just use a simple priority list when managing teams or working individually.

New issues are added to the list based on priority. And only “emergency” issues can pause current work to be paused.

Everything else is done face to face as needed without formal meetings.

It’s simple. It works.


The alternative from people who criticize agile is coming up with your own process or no process at all. Just do what you guys want that makes you productive.


After a multi-year scrum initiative where I work, we had a new leader come in who basically said this. "Do whatever you want." It was a nightmare (still is).

While it took several years to get people on board with Scrum, it finally started to pay off, where everyone was speaking the same language, dependencies were being called out and put into other team's backlogs, and the various ceremonies started to bear fruit, improving how the team was working.

When that playbook went out the window it was chaos, and it's been that way ever since. No one knows what anyone else is doing. Work is being duplicated all over the place. There are no priories... where everything is a priority and it shifts by the hour with new things being added. Everyone is in a firefight and doesn't see a way out.

The "do your own thing" approach probably works great for small teams and organizations, but quickly falls apart in large organizations with dozens or hundreds of teams trying to work together. The new guy who threw the playbook out the window was from a company 1/10th the size of ours. He doesn't understand the scale and that has been very clear.

I'm not advocating for SAFe here, I think that's its own nightmare. But some kind of shared framework so teams can work together and respect the boundaries of other teams is not a bad thing... whatever that framework is.

Within Scrum there is the idea of the retrospective, to adjust things as needed. If a team isn't seeing value in standups, planning poker, etc... don't do them. Things like that really only impacts the internal team, and the larger organizational cooperation can still exist. For example, my team never assigned points as a group, because it didn't make sense to us. The effort involved in a story is dependent on the skill and familiarity of the person working on it.


Rigid


First, Agile is not a process so it's not directly comparable to Waterfall (which is a specific process). Agile is an umbrella term for a set of concepts (processes, methods, philosophies) some of which can be compared to Waterfall, at least in part.

Second, don't pick a specific process. Develop a process. Select from the broad collection of ideas that go into processes, the components that you want based on their effectiveness or utility.

https://en.wikipedia.org/wiki/Software_development_process

The key things to decide when developing a process:

Feedback loops or no? If you don't like reality, then don't use feedback loops. For the rest of us, reality is what we live and work in so incorporate feedback loops. Don't use hard boundaries between phases with an assumption the previous work was correct. This means likely pushing for automated, regular testing (verification) and regular "customer" (whatever that means in your context) feedback (validation). Use the results to update plans, designs, requirements, and the system itself.

Small batch or big batch? The larger the work you deliver at once, the higher the risk. Delivery is when you get validation (that you built the right thing). If you have a team of 1k people building out your hot new shit and deliver after 2-3 years, you may find you spent a lot to build the wrong thing. Deliver smaller batches incrementally and you'll get validation (and verification, but critically validation) along the way. This also means you have to rollback less if there's an issue, if you have to roll anything back. Deploy a new validated (right thing) service after 2 years but find out you have a critical design flaw so it doesn't handle more than 1k concurrent users, well you may have to eat the scaling costs or rollback the release and fix the design. Smaller increments, better feedback, lower risk.

BDUF or no? Big design up front means committing (it's a design) to a lot of unknowns. Is the design even going to be relevant when you release? Is the time spent on it worthwhile? If you're delivering in smaller batches you get feedback and can adjust the design, but then why spend so much time designing everything? Design just enough between releases, how much is enough? Judgement. You know your team and market, you figure it out.

Waterfall: No feedback loops, big batch, BDUF. It's basically the highest cost, highest risk approach. It's stupid for any project that's going to last more than 6-12 months. (Any project that length or shorter that's not totally novel is likely to succeed or fail regardless of chosen process.)

Incremental (Classic): Waterfall with 6-12 month increments. Fixes the feedback loop and partially addresses batch size problem. Still has BDUF. Reasonable, but not great because you're still spending a lot of time on the design that could be invalidated.

Spiral (Classic): Incremental without BDUF. Some design and requirements at the start, but mostly done at the start of each increment which is still usually in the 6-12 month (maybe shorter) range. Addresses many of the issues of the above.

V-Model: Waterfall with much stronger emphasis on V&V, permitting some feedback as you go through the V&V portion of the work. Pair this with Incremental or Spiral and you actually have a somewhat reasonable model. Stick to V-Model as Waterfall with better V&V, you still have the big batch risks and BDUF problems.

If you look at the actual ideas in Agile and not just Scrum, you'll see that it ranges from somewhere along Spiral (just enough design and requirements to hit an MVP, evolve that toward your final product using feedback along the way) to the more extreme form of Kanban style where you work and deliver very, very small batches (potentially delivering every small change many times a day).

The big things to take away from every one of the models: Feedback loops reduce risk and increase the chance of success. Small batches reduce risk and increase the chance of success. Design up front, but not BDUF, reduces cost and some risks (that you build the wrong thing because the decision was made before it should have been).

Take those three things and then figure out the specific techniques (wherever they come from) that help you out. TDD is basically the tightest feedback loop you can get for software verification. Is it appropriate for everything? Maybe, maybe not. Things of that nature.

NB: Spiral and the various Agile methodologies and techniques work even in critical and safety systems. In aviation for a new aircraft, building a safety-critical LRU the first deliverable might just be a form and fit check that supplies canned messages over the avionics network (this is used in initial integration testing on the ground). The next deliverables will push toward meeting flight safety requirements for the first flight tests. Then the next series will add capabilities required for certification but not for flight test. The final series will be further "quality of life" refinements that the customer wants, or maybe to work with specific variants for specific carriers or nations.

You don't need Waterfall or BDUF for anything.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: