6 ms·

Ask HN: What's the Alternative to Agile?

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?

deterministic 2y ago
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.
NoPicklez 2y ago
Rigid
meyerluanna 2y ago
[dead]
bakioka 2y ago
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.
- al_borland 2y ago
  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.
solardev 2y 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.
- 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.
Jtsummers 2y ago
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 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.
simonhfrost 2y ago
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.
shsbdncudx 2y ago
Read the agile manifesto and tell me you don’t want to do those things…
- animal_spirits 2y ago
  Yeah but I’m looking for proven alternatives. No one says agile is perfect
  - CRConrad 2y ago
    > No one says agile is perfect Read the agile manifesto and tell me what you want to do that isn't in there.
    - a-saleh 2y ago
      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
- funcDropShadow 2y ago
  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.
  - andrei_says_ 2y ago
    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 https://www.youtube.com/watch?v=a-BOSpxYJ9M
  - shsbdncudx 2y ago
kevg123 2y ago
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.
- Jtsummers 2y ago
  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.
pablogancharov 2y ago
Shapeup https://basecamp.com/shapeup https://basecamp.com/shapeup
- vladsanchez 2y ago
  Thanks for sharing. I never heard/knew of this one.
mergisi 2y ago
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.
- hu3 2y ago
  this is heaven for ADHD folks
joe8756438 2y ago
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 https://hedgerider.substack.com/p/agile-for-anarchists
deleted 2y ago
[deleted]
a-saleh 2y ago
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.

deterministic 2y ago

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.

NoPicklez 2y ago

Rigid

meyerluanna 2y ago

[dead]

bakioka 2y ago

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.

al_borland 2y ago
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.

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

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.

Jtsummers 2y ago

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

simonhfrost 2y ago

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.

shsbdncudx 2y ago

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

animal_spirits 2y ago
Yeah but I’m looking for proven alternatives. No one says agile is perfect
- CRConrad 2y ago
  > No one says agile is perfect Read the agile manifesto and tell me what you want to do that isn't in there.
  - a-saleh 2y ago
    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
funcDropShadow 2y ago
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.
- andrei_says_ 2y ago
  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 https://www.youtube.com/watch?v=a-BOSpxYJ9M
- shsbdncudx 2y ago

kevg123 2y ago

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.

Jtsummers 2y ago
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.

pablogancharov 2y ago

Shapeup https://basecamp.com/shapeup https://basecamp.com/shapeup

vladsanchez 2y ago
Thanks for sharing. I never heard/knew of this one.

mergisi 2y ago

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.

hu3 2y ago
this is heaven for ADHD folks

joe8756438 2y ago

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 https://hedgerider.substack.com/p/agile-for-anarchists

deleted 2y ago

[deleted]

a-saleh 2y ago

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.